Extracting Dosfs
Victor V. Vengerov
Victor.Vengerov at oktetlabs.ru
Fri Oct 15 15:41:25 UTC 2004
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