IMFS: yet another trouble.

[Joel Sherrill]

Sergei Organov wrote:
> 
> jennifer averett <jennifer.averett at oarcorp.com> writes:
> [...]
> > > Oh, yes. As always I've already found it myself yesterday. Now everything
> > >works just great! I'd like to mention in addition that 'st_dev' and 'st_ino'
> > >fields of 'struct stat' should be set in the file-system 'fstat' routine to
> > >some unique values, otherwise 'getcwd()' doesn't work. It'd be fine to
> > >mention this fact in the documentation if it's not already there (at least I
> > >didn't find it).
> > >
> > >
> >
> > This points to a problem in the IMFS, st_dev is only set if the node is a
> > device node.  Looking at getcwd I have a question: This code is identifying
> > the root node by the combination of st_ino and st_dev.  This implies that on
> > a given device no two nodes can have the same identity.  We have no
> > guarantee of this.  Currently each file system assigns its own node id, (in
> > the IMFS this id is based upon instance of the file system - therefore if
> > the file system were mounted twice there would be two nodes with the same
> > id).
> 
> As far as I understand, the idea behind st_ino and st_dev pair is that in pair
> they identify a node uniquely. 

I did not find this explicitly in POSIX although it seemed
implied by a Rationale I found.  But it is pretty clear in
the UNIX98 standard.  This leads us to the next set of comments 
very naturally. :)

FYI Jennifer and I seemed to take a similar wandering path 
in our discussion.

> Usually st_ino is block number on some device
> (unique within device) 

Not necessarily a block number.  It is similar a file sequencing
number.  I think it should be guaranteed to be unique per 
filesystem instantiation.   

> and st_dev is device id (globally unique number). 

Exactly.  

> For
> in memory file system, the st_dev could be some arbitrary unique number that
> is the same for all instances of IMFS (in fact it tells that device is RAM),

This is a possibility.  It is also a possibility that it could have
a unique and arbitrary major number with the minor number indicating
the "instantiation" of the IMFS.  First IMFS mounted is 0, 2nd is 1, 
etc.  This allows the st_dev to still start at 1 and simply
increment per instantiation of the IMFS.

> and st_ino could be just unique pointer, e.g. pointing to the beginning of
> particular file. 

This would be OK when sizeof(void *)==sizeof(unsigned32).  But it
promotes out something I am not sure is a good idea.  Seems to
put an address in "user space" that is dangerous.

> The st_dev should change if IMFS instance is working on top
> of some device other than RAM, e.g., NVRAM or something that doesn't share
> address space with RAM and thus st_ino values on that device may match those
> in RAM by collision.

Right now, the scheme most discussed is adding a (void *) per filesystem
pointer to the mount() call (ala Linux).  The IMFS has no way to
know what it is.  It is possible to mount it twice with a NULL
configuration
table. 

I suppose it could be its mount table entry point also but that 
has an odd chance of colliding/promoting out something.

> In fact, AFAIK, in most Unixes st_dev is also subdivided to major and minor
> device number. The major number then  specifies a class of devices, and minor
> number -- particular device of the class. To mimic this it's possible to
> assign arbitrary unique major number to RAM, and use minor number 0 for
> current instances of IMFS because all of them operate on the same device, --
> RAM.

st_dev is the same for devices under the IMFS.  stat() /dev/console
to check it out. :)

But the device number for what the IMFS is mounted on falls into a
huge black hole.  It is meaningless but has to be unique.  I like
the idea of an arbitrary major with minor indicating the instantiation
but see no particular strong case for any of the alternatives.
Discussions are open. ;)
 
> Best Regards,
> Sergei Organov.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985