libio preparation for file systems

[Robin Kirkham]

On Thu, 26 Feb 1998, Joel Sherrill wrote:

> > In simple RTEMS systems, the new libio would manage just one of these 
> > filesystems, which would be the root filesystem. The two together would 
> > provide the current libio functionality, but with huge potential for
> > expansion. In more complicated systems, this memory filesystem provides
> > points to mount other filesystems on, even other invocations of itself.
> 
> 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.

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.

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.

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.


> 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()).

> > 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.

Cheers,

Robin