Vnode ops in VFS layer of Kernel (esp. SUN)

[Guy Harris]

>=>	What are "vnodes"???
>=
>=In a nutshell...
>=
>=Vnodes are very similar to the System V file system switch.  ...

Well, that's often the way "vnodes" is used, but I prefer saying "the
VFS mechanism is similar to the System V file system switch."  The VFS -
Virtual File System - mechanism is, in fact, a mechanism similar to the
S5 File System Switch, as described by Conor.

Vnodes are the objects that represent files (or, if you consider entries
in "/proc" not to really be files, nonfiles as well) in systems that
implement the VFS mechanism.

>What is the SV file system switch?

The System V File System Switch is very similar to the VFS mechanism.  :-)

Seriously, they both implement the same general sort of facility. 
Operations that act on files (whether looking up pathnames and getting
the file to which they refer, or reading or writing or getting "stat()"
information or whatever from a file, or...) will go through a "switch"
depending on the type of file system on which the file resides.

The file might reside on, say, an S5 file system, or a BSD file system,
on a disk local to the machine, or it might reside on another machine to
be accessed by RFS, or by NFS, or it might reside on a "non-file
system", such as "/proc".  If, say, you're doing a "read()", it'll call
the routine that does "read"s for S5 file systems if the file resides on
an S5 file system, or for BSD file systems if it resides on a BSD file
system, or....

The file system switch and the vnode mechanism differ in many details,
but the details aren't very relevant to the general concept.  Several
implementations of the vnode mechanism exist in various flavors of UNIX;
the differences are generally minor, and largely consist of operations
being added (admittedly, in some cases the new operations aren't minor,
e.g. the new operations added in the SunOS 4.0 vnode layer for
interfacing to the new VM system).

Other systems may have other such mechanisms, such as the "gnode"
mechanism in Ultrix.

>Is it true that vnodes and inodes are not at all related?

Vnodes represent "generic" file (or nonfile, as indicated) objects; they
contain a pointer to a table of procedures that are the "operations" on
the vnode, such as "lookup a file name in this object if it's a
directory", "read from the object" (or "read or write from the object
depending on an argument to the function", in some versions of the VFS
mechanism; I think the S5R4 one may separate the "read" and "write"
functions into separate procedures), etc., and a pointer of type "caddr_t"
that points to "private data" for the vnode.

They also contain other data that's generic to all vnodes, such as:

	a set of flags;

	a type indicating whether the file to which the vnode refers is
	a plain file, a directory, a symbolic link, etc.;

	and so forth.

The "private data" is data private to the type of file system on which
the file represented by the vnode resides.  In the case of a file on an
S5 or a BSD file system (or probably other UNIX file systems), this
private data is, in fact, an in-core inode.  The in-core inode, in turn,
contains the vnode that refers to it as a member:

	struct inode {
		various inode stuff
		struct	vnode i_vnode;	/* vnode associated with this inode */
		more inode stuff
	};

with the "v_data" member of "i_vnode" pointing to the inode itself. 
I.e., if you have an inode named "inode",

	(struct inode *)inode->i_vnode.v_data == &inode

That is the extent to which vnodes and inodes are related.

Other vnodes do *not* point to an inode; for example, a vnode for a file
on an NFS file system points to an "rnode".  The rnode, in turn,
contains the vnode that refers to it, just as an inode contains the
vnode that refers to it.