Extracting Dosfs

Daniel Gustafsson daniel.gustafsson at space.se
Thu Oct 21 06:42:52 UTC 2004



Hello.


Victor wrote in a previous mail:

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...


I really would appreciate a more detailed explanation how to redesign (what
to remove) the LIBBLOCK interface. I have removed the semaphores but now I
have some wonderings about the tasks etc. How much can I remove and what is
neccesary for it to work properly. I am interested in a single thread
design.



//Daniel



>-----Original Message-----
>From: Victor V. Vengerov [mailto:Victor.Vengerov at oktetlabs.ru] 
>Sent: Friday, October 15, 2004 5:41 PM
>To: joel.sherrill at OARcorp.com
>Cc: Bogdan Vacaliuc; 'Daniel Gustafsson'; rtems-users at rtems.com
>Subject: Re: Extracting Dosfs
>
>Joel,
>
>Yes, you are right. I'll try to manage myself and finally do this.
>
>Victor
>
>Joel Sherrill <joel at OARcorp.com> wrote:
>
>> 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
>>>>  
>>>>
>>>
>>>
>>
>>
>
>
>-- 
>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