Extracting Dosfs

[Eugeny S. Mints]

Hi Danial,

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 
compilation time.
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 
cpukit/libblock.

> 
> 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 wishes,
			Eugeny Mints
> 
> Best Regards
> Daniel Gustavsson
> 
> 
>