libio preparation for file systems

[Joel Sherrill]

On Fri, 27 Feb 1998, Robin Kirkham wrote:

> > Are you proposing that there be a "device management" file system which
> > according to current (and UNIX) convention is mounted onto /dev?
> 
> No. I think the memory file system would initially have directories and
> device nodes. Our /dev would be a directory; /dev/console would be a device
> node. Thus, one invocation of the memory filesystem is sufficient to give
> the current libio funtionality.

OK.  That was what I had in mind.  the "memory filesystem" knows about
directories, devices, and mounting.  

> Later, it could be extended to include some of these other ideas, like
> command "executables" linked to functions, and RTEMS object names, and
> file-like objects. You can do these as filesystems in their own right as
> well. The problem with having many special-purpose filesystems is that you
> can only have objects of the types supported by those filesystems in the
> directories where you mounted them, and not just anywhere.

At some point int he future, it will have to be decided which is the best
way to go.  I suspect that one can find a way to integrate those
capabilities into the memory file system without incurring a huge penalty
in minimum system requirements.  Somehow the pieces will have to be
installable.  So you could have "installable file types" as well as
installable file systems.

> So I think it would be better to slowly work some of these other (worthy)
> ideas into the memory filesystem, but leave some of the more unusual things
> (like discrete IO) to have special-purpose filesystems.

Sounds reasonable. 

> Might I propose a name for this "RTEMS memory filesystem" so I can stop
> typing "nenory filewyste," 8-) What about rmfs. It would be the non-persistent
> filesystem for RTEMS things.

OK. 

> > I think it is important for the memory file system to allow mounts of
> > itself.  I don't think this is particularly a problem just something to
> > make sure works. :)
> 
> Mounting would be a property of the new libio, not the filesystems, which
> don't actually know where thay are mounted, or if something is mounted
> on them. So, you should be able to mount anything on anything. To make sense,
> and so the directory tree stays together, all a mount should require is 
> that the mount point exists and is a directory (same requirement as chdir()).

Does "new libio" == "memory file system"?  

If the answer is yes, then I think I understand.  If the answer is no,
then I am unsure of the division you have in mind. 

> > > This does remind me: for NFS (a very useful, and fairly easily implemented
> > > filesystem, once someone ports RPC) does imply a basically working
> > > getuid(), getgrpid(), getgroups() set-up.
> > 
> > Some of these routines are already implemented but tend to return
> > variables which may be set via the set*() routines.
> 
> Yes, I've just tracked down where they are and had a look. With NFS, however,
> uid/gid and gids have to be correct for the server host, and so you have to
> get this information from it ... anyway, this does not impact on the task
> at hand.

OK.  They were just intended to "be there and not be wrong". :)  We will
have to work on those as part of a future NFS effort. 

--joel