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