Extracting Dosfs

Bogdan Vacaliuc bvacaliuc at ngit.com
Fri Oct 15 14:24:08 UTC 2004


Hi Daniel,

I would draw the diagram more like this:

   USER
     *
     |	
   LIBCSUPPORT
    |     |
    |   DOSFS (MSDOS*PREFIX)
    |     |
    |   DOSFS (FAT*PREFIX)
    |     |
   LIBBLOCK
     |
   DRIVER
     |
     *
SPECIFIC HARDWARE


This is why Victor was alerting you to the fact that 'libblock' uses RTEMS synchronization mechanisms (such as semaphores).  I draw
the parallel line from LIBCSUPPORT to LIBBLOCK since it is possible to open/read/write devices directly (such as you would do when
'formatting').

> What are the constraints of the FS (max partitions etc.). I want to
> run on a system with approx eigth partitons with 1GB each.

Each FS is mounted on a region of the block device.  The FS code itself does not interface with the partition table directly; there
are some utilities in libblock for parsing partition tables.  So there is no constraint by the FS on partitions.

The typical constraints we see with disks is that the MSDOS Master Boot Record only defines 4 (primary) partitions, and a method to
specify one of those as an extended partition with any number of logical partitions.  [additional "reserved" sectors are used on the
disk to store these tables].  RTEMS has code to deal with this in cpukit/libblock/src/ide_part_table.c, etc.  However, I do see that
RTEMS does not have code to deal with non-MSDOS partition tables, so keep that in mind.

So you should not see any constraints related to max partitions even if they are all on the same block device, and you certainly
will not have constraints if you have multiple devices.

Eugeny has already said that "All constraints come from original FAT12/16/32 design itself".  I did not research deeper into the
long filename support in the current DOSFS implementation.


Good Luck!

-bogdan


On Friday, October 15, 2004 2:48 AM, Daniel Gustafsson wrote:

> Thanks for the answer...
> What are the constraints of the FS (max partitions etc.). I want to
> run on a system with approx eigth partitons with 1GB each. 
> 
> I am going to try to extract dosfs for Rtems for a couple of days. If
> I understand correctly the file system structure are as follows: 
> 
>    USER
>      *
>      |
>  LIBSUPPORT
>      |
>    DOSFS (MSDOS*PREFIX)
>      |
>    DOSFS (FAT*PREFIX)
>      |
>    DRIVER
>      |
>      *
> SPECIFIC HARDWARE
> 
> 
> If I am totally wrong, please correct me.
> 
> 
> Regards
> Daniel
> 
> 
> 
>> -----Original Message-----
>> From: Bogdan Vacaliuc [mailto:bvacaliuc at ngit.com]
>> Sent: Friday, October 15, 2004 3:02 AM
>> To: 'Daniel Gustafsson'
>> Cc: rtems-users at rtems.com
>> Subject: RE: Extracting Dosfs
>> 
>> Ugh.
>> 
>>> inside an RTEMS environment.  The code is stand-alone and compiles
>>> readily under GNU/Linux, Cygwin, etc.
>> 
>> I lied when I said it compiles readily.  Two years ago was
>> when I started with it...  Funny, I remember whipping it together and
>> demonstrating its functionality quite quickly.  Sigh.  I guess
>> it will just take a little more time and coddling that I expected.
>> 
>> -bogdan
>> 
>> 
>> On Thursday, October 14, 2004 10:52 AM, Bogdan Vacaliuc wrote:
>> 
>>> Hi Daniel,
>>> 
>>> You may want to follow the ongoing "Formatting DOSFS volume" thread
>>> in RTEMS: 
>>> 
>>> http://www.rtems.com/ml/rtems-users/2004/october/msg00086.html
>>> 
>>> The RDCF2 code (http://alumnus.caltech.edu/~pje/rdcf2.txt) may be
>>> just what you are looking for if you are not interested in running
>>> inside an RTEMS environment.  The code is stand-alone and compiles
>>> readily under GNU/Linux, Cygwin, etc.
>>> 
>>> Best Regards,
>>> 
>>> -bogdan
>>> 
>>> 
>>> On Thursday, October 14, 2004 9:37 AM, Victor V. Vengerov wrote:
>>> 
>>>> Daniel,
>>>> 
>>>> Have in mind that libblock depends on some RTEMS synchnorisation
>>>> mechanisms, and run the thread writing blocks to the disk. Also,
>>>> ms-dos file system and libblock has been designed with
>>>> mulithreading in mind, which may be overhead for you. More free
>>>> open-source MS-DOS implementations are exists (I remember freedos
>>>> name, although I'm not sure) - may be it is better appropriate for
>>>> you. 
>>>> 
>>>> I don't know what are you going to implement, but it will be
>>>> definitievly simpler to link your application with RTEMS,
>>>> considering it as a library providing some services, particularly
>>>> DOS file system. Nothing prevent you to implement single-threaded
>>>> application in RTEMS - just run it as a initialisation task.
>>>> 
>>>> Victor
>>>> Daniel Gustafsson wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> I am interested in extracting Dosfs in Rtems 4.6.1 to a separate
>>>>> module that shall work stand-alone with a commandpromt. The module
>>>>> should use a block based ram driver like a simulated disk. Before
>>>>> I start I would like to ask if somebody has done the same thing or
>>>>> knows any good approaches? The main questions I would like to have
>>>>> an answer to is the following:
>>>>> 
>>>>> 1. What does the file structure of dosfs look like? Which files
>>>>> are necessary for a stand-alone module? Which files are connected
>>>>> to the different layers (driver, upper interface etc.) of the
>>>>> file system? 
>>>>> 
>>>>> 2. Where should I start? Any tips is greatly accepted?
>>>>> 
>>>>> 3. Can somebody tell me about any constraints or limitations of
>>>>> the fs (max partition size etc.)? 
>>>>> 
>>>>> 4. Does anyone know the footprint of dosfs in RAM during runtime?
>>>>> 
>>>>> Best Regards
>>>>> Daniel Gustavsson




More information about the users mailing list