libio preparation for file systems

[Robin Kirkham]

On Tue, 24 Feb 1998, Joel Sherrill wrote:

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

It's occurred to me that if we have an effective system of mountable
namespaces, which are easy to implement, you can have the best of both worlds.
You would write your ADC driver (or whatever) not as a driver, but as one 
of these namespace/filesystems. This particular space would implement 
a flat namespace consisting only of numbers, one for each channel. This 
you would mount on, say, /dev/adc, so that the ADCs were /dev/adc/0,
/dev/adc/1, and so on.

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

Wouldn't worry me if it were 0% UNIX.

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

I don't think it's that tough--multithreaded UNIX is of course like that,
as is vxWorks. The task extension hooks are there for applications to make
this a per-task property if they really want (but getcwd() had better be
fast!)

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

I think the filesystem interface is already essentially defined by the set
of POSIX operations already mentioned. Practically, you would have a
filesystem class (type) declaring these operations, and real filesystems
("memory", flash, MS-DOS, NFS, ...) would be objects of this class.
libio would deal with these objects and their relationships.  The only
operations they would not have to implement would be mount(), umount(),
getcwd(), chdir(), because libio would do these.

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

Yes and yes. This is what normally happens (filesystems don't know where they
are mounted). It has to be that way, because otherwise libio would need to
know too much about the internals of the filesystem. For a start, it would
need to know what the directory separator character was (some filesystems
don't use /, or in flat ones / has no significance).

This suits us, because it makes libio simpler, which will keep systems that 
need minimal namespace functionality happy 8-)

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

Well there's no accounting for currency fluctuations in this part of the
world!

Robin