From: Love <lha_at_stacken.kth.se>
   Date: 10 Feb 1998 22:28:33 +0100

   Still, not all people will run linux, I guess that you should
   create a way to put wrappers around all this so your server
   dont know what it's using. But why create two interfaces ?

The problem with the iopen(dev, inode), etc. calls, is that Linus
refuses to have such things in the VFS layer.  I can't really blame him,
since the whole concept of "inode number" is extremely filesystem
specific, and doesn't have meaning in many filesystems.  

AFS for example, will "make up" inode numbers, but since an AFS cell can
hold many more files than 2**32, the "made up" inodes numbers are not
guaranteed to be unique.  The same is no doubt true for Coda.  So,
something like iopen() is NOT a general interface, and does not belong
in the VFS layer.  Linus has stated he will not entertain having an
iopen() system call, and quite frankly, I have to agree with him.

The iopen(dev, inode) interface also has the problem that it assumes
that in the future we will continue to have valid device numbers.  In
the future, this may be a bad assumption, if devfs becomes a reality.

The advantage of simply using the open() system call with a magic system
name is that it doesn't require any changes to the VFS layer.  Because
it's architecturally much cleaner, it increases the chances we can get
these chances into the mainline Linux kernel.

Now, in the Coda code, it's perfectly reasonable to have a generic,
OS-independent abstraction layer.  I'd suggest something that's general
enough that a Solaris-specific function would be able to derive the
device number of the partition, and hence be able to call iopen, or
under Linux, the OS-specific function should be able to derive the
partition mount point, so it can make the appropriate open() call.

						- Ted