Eugeny S. Mints
emints at ru.mvista.com
Thu Oct 14 12:42:59 UTC 2004
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.
Frankly speaking I haven't got your idea what does the separate
stand-alone module with commandpromt mean. There is no loadable modules
functionality in RTEMS even an application links with RTEMS core at
Could you please clarify a bit your target?
>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?
The whole implementation is located in cpukip/libfs/src/dosfs.
>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?
Well, dosfs specific part (directories structure, a file/directory
descriptors, file sizes, etc) is in msdos_* prefixed files and sits on
top of "fat files" implementation (fat_* prefixed files). "fat file" is
nothing more as "a chain of clusters(blocks)". "fat file" sits on top of
libblock cache (direct calls to rtems_bdbuf_read/write) and utializes
diskdevs interface (interface to physilac/logical disks, rtems_disk_* ).
diskdev subsytem interfaces with a block device driver via driver
provided ioctl routine.
All block devices related things (cache, diskdevs) are located into
> 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.)?
All constraints come from original FAT12/16/32 design itself. THus you
might want to read M$ FAT whitepaper - ask google for it.
The only implementation constraint I remember is absence of long names
support. Though I may forget something.
> 4. Does anyone know the footprint of dosfs in RAM during runtime?
Since dosfs uses block devices cache to deal with files data and
metadata the RAM footprint of dosfs is well tunable via block devices
cache setup. The size of essential data structures of the fs itself is
really minimal though I never calculate the exact number.
> Best Regards
> Daniel Gustavsson
More information about the users