libio preparation for file systems

[Joel Sherrill]

On Thu, 26 Feb 1998, Robin Kirkham wrote:

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

Cool idea.  This would be a very good way to do the discretes.  You could
even have the names as word-start-width-return_type.  So 0-3-15-32 would
read work 0, starting at bit 3, for a width of 15, and return it in
an unsigned32.  Having mountable file systems of varying types is a very
powerful thing.

I have nearly reached the conclusion that enhancing the current libio by
adding directories and mounts will provide nearly all the functionality
required.  

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

We all want some "unix" -- just having a good C library gives you an
amazingly high degree of compatibility.  But I don't want to go overboard
to the point of destroying the basic performance characteristics.

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

It is not the multi-threaded semantics that are the problem.  They are
pretty clear in the POSIX spec.  The problem is that much of POSIX assumes
multiple processes.  There are oodles of references to process ids, group
ids, process groups, fork/exec/wait, etc.  Some of this is hard to decide
what it means (if anything) in a single process environment.

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

I think so too.  That is why I have already started discussions with the
newlib maintainers to see what all has to be provided to support more of
newlib.  Rather than trashing the current scheme and starting over, it is
just time to use more of the interface with newlib.  

And questioning .. wouldn't libio need help from file system code to do a
"chdir"?  THe organization of each directory is a function of the file
system.  I guess you would at least need some "helper" functions from the
file system.

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

OK.  Then you agree that chdir() would have to do some file system
specific stuff to at least validate the remaining path name.

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

I think that adding directories and mounts does not have to add a lot of
code.  In fact, if libio is split into multiple files, you might even lose
code which is alwyas pulled in now.

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

<grin>  

--joel