libio preparation for file systems

[Joel Sherrill]

On Tue, 24 Feb 1998, Robin Kirkham wrote:

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

The major/minor numbers are there because the RTEID specification included
them.  This is the same specification pSOS+ and VMEexec are based upon.

Whether this is the best way or not, I have not realy thught much about
it.

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

It certainly could be done this way, although the major/minor number
scheme has its advantages also.  For discrete IO device drivers we have
used the minor number to encode the word, starting bit, and width for a
bitfield on a board. Analogs are easy with major/minors also.  I can see
where one could have "/dev/adcNN" but the discrete naming scheme would be
worse.

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

This is a good argument for looking at this.

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

It will.

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

If I could understand them enough to get mislead. :)  They are very
complicated.  You are right that having the semantics is important but
having the actual implementation 100% UNIX is not.

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

Yep.  Some of these have problems in that the semantics are tough in a
single process OS like RTEMS.  For example, I think getcwd() is defined to
set cwd for a process -- the entire system on RTEMS.  But the idea is
right.  We need that list of functionality.

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

Sounds reasonable.  It would be nice to work out the interface to file
system implementations since one of the impetuses for this was the mention
of a Flash File System on the list.  I wanted to get that part of the
world right before we began hanging even more off the current scheme in an
adhoc fashion.

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

I think that is the key.  I need to add a sense of hierarchy to libio as a
starting point, then add the ability to mount.

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

Is a file system implementation responsible for walking its own directory
system?  For example once libio descends to a "mounted entity", should the
remaining path be passed on down and parsed by that file system entitiy?

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

I believe you are right on this.

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

Actually it is easier to use termios than to ignore it. :)

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

If it is the same, I got more out of it this time. :)

--joel