Extracting Dosfs

Victor V. Vengerov Victor.Vengerov at oktetlabs.ru
Fri Oct 15 15:24:10 UTC 2004


Daniel, Bogdan,

I would like to provide little more detailed drawing:

   USER
     *
     |	
   LIBCSUPPORT
    |     |
    |   DOSFS (MSDOS*PREFIX)
    |     |
    |   DOSFS (FAT*PREFIX)
    |     |
   LIBBLOCK
     |
PROTOCOL DRIVER
(currently it is IDE only,
in the future it will be SCSI etc)
     |
HARDWARE DRIVER
(i.e. driver of specific
 IDE controller)
     |
     *
SPECIFIC HARDWARE

"Protocol driver" layer remains the same for, let say, IDE hard disks, 
compact flash etc. Hardware driver is a libchip-style driver which is 
totally hardware dependent (although many IDE controllers are very 
similar, it is not mandatory; particularly in device we are working 
with, IDE controller were implemented in FPGA and has it's own interface.

In theory, Daniel may re-design LIBBLOCK interface, removing everything 
about concurrency, semaphores etc, and making write to/read from the 
media immediately (assuming he is interested in single-threaded design). 
But I'm not completely sure...

Victor

Bogdan Vacaliuc wrote:

>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 Gustavsso
>>>>>>
>n
>  
>


-- 
Victor Vengerov
OKTET Labs, St.-Petersburg, Russia  http://www.oktetlabs.ru
Phone: +78124286709 (office) +78129389372 (mobile) +78124281653 (home)




More information about the users mailing list