Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.questions
Subject: Re: Vnode ops in VFS layer of Kernel (esp. SUN)
Message-ID: <1990Oct09.125630.6510@virtech.uucp>
Date: 9 Oct 90 12:56:30 GMT
References: <545@public.BTR.COM> <1990Oct6.200834.539@mccc.uucp>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 30

In article <1990Oct8.152338.7543@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes:
>What is the SV file system switch? 

The SV file system switch was developed by AT&T to solve the same problems
that the VNODE FS solves.   Essentially it was to separate the low level
file system dependent portion of the kernel from the high level file system
independent portion of the code.  This break makes it much easier to 
add new file systems to the kernel without having to modify the system
call interface.

The file system switch is actually an array of structures (one entry for
each file system type) that contain pointers to functions for each file
system operation (open, close, set attributes, read, write, etc).

When you make a system call the file system independent portion of the
kernel will process your request and then call the appropriate file system
dependent function (using the entries in the file system switch) to 
complete the operation.

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

They are related.  The vnode structure contains a data pointer that usually
refers to an inode (assuming the underlying file system has inodes) that 
is associated with that vnode.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170