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