libio preparation for file systems

[Robin Kirkham]

On Mon, 23 Feb 1998, Joel Sherrill wrote:
> I am beginning to look at adding the infrastructure for
> a more robust name space in RTEMS.  libio was orignally
> designed to map device names into major/minor pairs and
> pass IO request through to device drivers.  Since that
> time, it has been augmented to support sockets.

I've always wondered why RTEMS actually has these major/minor numbers.
They are a Unix sort-of-thing, because Unix must encode the entry points 
of a device driver in a directory block (node). The nodes are stored on
disk, obviously can't have kernel entry addresses or anything like that
stored in them. The major/minor numbers give a level of indirection.

In RTEMS I can't see why they are necessary. The device name entries (as
they are now) could contain pointers to the actual device driver entry
points, because the device name entries are installed into the libio data
structures by the BSPs during startup. This is what happens in vxWorks
(although I have problems with other aspects of the vxWorks IO system,
which I hope is what this exercise is trying to avoid).

If the major/minor number stuff could be eliminated (really, subsumed) it
might "pay for" the extra complexity of a heirarchical namespace. It would
mean changes to all the BSPs, but these might be simplifications as well.

> I would like to start getting the infrastructure in place
> to be able to mount file systems, walk directory trees
> of "/dev", etc.  Essentially have a better "logical
> file system."

Not just "/dev" I hope: it should start from "/".
 
> Right now, I am looking at the way this is done in various
> free UNIces (Linux and NetBSD).  I would like suggestions
> on what capabilities you folks would like to see in
> this area.  If you have ideas about possible implementations 
> we could look at.

I think that the *semantics* of the Unix hierarchical directory system,
and the programmatic interface to this (as defined by POSIX), are what is
needed, and which should be the starting point. The implementation would
be very different, I think, to the extent that Linux/NetBSD examples would
border on the misleading.

There needs to be a generic "filesystem" class, which provides the 
standard operations open(), close(), read(), write(), ioctl(), mkdir(),
stat(), rmdir(), mknod(), unlnk(), mount(), umount(), opendir(), readdir(),
select(), getcwd(), and probably a few others.

"Filesystem" objects would implement all, or only some, of these operations,
as appropriate, and with the limitations inherent in the actual filesystem
they use (e.g., 8.3 MS-DOS filenames, no concept of mounting; NFS filesystem,
no notion of device nodes; RT11 (remember that?), no directories; etc).

RTEMS libio would manage these "filesystems" and know about the mount-points,
manage the "current directory", the file descriptors and the file table.
At the moment, libio only deals in device nodes in a flat namespace.

There would also be a RTEMS "memory" filesystem, which would be managed by
the new libio just like the others. One would used for the root "filesystem",
so it would need to handle only directories, mount points, and device nodes.
It would be very simple, because it need not be persistent like a Unix root
file system, and it need not implement "files" or any real storage at all.

Although it should complicated, I think it can be done without a great deal
more code and memory than the current libio/IO Manager and "pretend" IO
code it would replace. A clever design should be able to attain the simplicity
and performance Aleksey wants:

> Just as an exmaple count what percentage of file I/O flags is not
> supported  currently by /dev/console. It is OK as long as we all
> implicitly know what console can and cannot do, but once we will get
> into device abstraction, all devices would have to support common 
> functionality, which can (a) affect performance, (b) be a severe 
> overkill in many many cases.

I think this is about naming devices, not about defining what the devices
actually do. It's certainly independent of whether serial drivers choose 
to implement all the termios jazz or not.


Another $0.02c worth from me (possibly the same $0.02c as last time?)

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