Extracting Dosfs

Fri Oct 15 15:28:50 UTC 2004

Victor,

I don't know where that picture and explanation needs to be
capture but it really needs to be placed in the documentation
somewhere. :)

--joel

Victor V. Vengerov wrote:
> 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
>>  
>>
> 
> 

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985