Flash File System

[Joel Sherrill]

I hate to just append a message to a reply but ...

I think Robin has identified a weakness in the current implementation that
needs to be plugged before too much more stuff is hung off the current
libio code.  This scheme should address the problems Robin mentions as
well as support doing "remote IO" through a host.  I would like to see
support for an IO server which ran on a "real host" at some point in the
future also.

Any file system support added should ideally plug in between  standard
layers like the tree-structure memory filesystem in Robin's words and a
device driver interface.

Does anyone know of a good starting point for this type of code?  VSTa,
BSD, Linux, etc?  Remember that we don't want to pick up any licensing
problems.  

It would be nice to strive for a "community design" and start identifying
the pieces.  

--joel


On Thu, 12 Feb 1998, Robin Kirkham wrote:

> 
> > I need a Flash File System for a project i am building with the RTEMS. I
> > will attempt to create this so that it can be incorporated into the project
> > as a whole.
> > 
> > 1. Is there anything i should be aware of before i do this. Especially with
> > regard to submitting the code for inclusion in future versions of RTEMS.
> > ...
> 
> I don't have anything that will help Steven directly (although I once fiddled
> with some code that built an MS-DOS filesystem in a battery-backed up RAM
> unit--this was on vxWorks which already has all the filesystem code).
> 
> It does raise an interesting point, however, that of filesystems and RTEMS:
> it has been talked about before on this list.
> 
> Usually, small kernels like RTEMS and vxWorks have a device table of some
> kind, with name entries which link to driver code. This is fine for a small
> number of entries--such as /dev/console, /dev/tty0, and so on. When a "file"
> is open()ed, the name is matched against each entry in turn. The / character
> has no particular significance, except (at least in vxWorks) if it is missing
> from the file name to be opened, another string, the "current directory" is
> prepended before the search.
> 
> The problem comes when real file-systems come along. vxWorks has a number of
> these--RT11, MS-DOS, NFS and a few others by now I expect. These are integrated
> into the driver-name scheme described above. It works well enough, until
> someone expects UNIX-filesystem semantics to apply throughout, and tries to
> open "/fred/../dev/tty0". Or expects an ls-like program to work in / or /dev.
> 
> I think RTEMS can do a little better. What is needed is a virtual,
> tree-structured memory filesystem, with all the proper semantics (i.e.,
> /, ., and .. work, etc). I imagine directory entries would reference vnodes
> of some kind, which would reference driver major/minor numbers, or inodes
> of a real filesystem.
> 
> In other words, I think there should be a consistent structure onto which
> drivers for real file-systems, such as flash cards, NFS (given we have ka9q,
> it's not a big step to port RPC and NFS) and, lord help us, real disk drives,
> can be mounted. The structure really should be in place *before* these other
> filesystem come along.
> 
> Just my $0.02 cents worth (actually, $0.017 given the current state of AUD).
> 
> Cheers,
> 
> Robin Kirkham			CSIRO Manufacturing Science and Technology
> Project Engineer		Locked Bag 9, Preston 3072, Australia
> robin.kirkham at mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851
>