ash@btr.btr.com (10/05/90)
Can anyone out there help me, I need to know what the following vnode functions
in the VFS layer of the Kernel do, especially in SUN OS4;
vn_getpage()
vn_putpage()
vn_map ()
I would really like to know what the arguments to these functions are and how
best to implement them. We have already implemented all the required VNODE
functions except the above, as we do not know what they do.
Thanks in advancepjh@mccc.uucp (Pete Holsberg) (10/07/90)
In article <545@public.BTR.COM> ash@btr.btr.com writes:
=
=Can anyone out there help me, I need to know what the following vnode functions
What are "vnodes"???
Thanks,
Pete
--
Prof. Peter J. Holsberg Mercer County Community College
Voice: 609-586-4800 Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91cpcahil@virtech.uucp (Conor P. Cahill) (10/07/90)
In article <1990Oct6.200834.539@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: > What are "vnodes"??? In a nutshell... Vnodes are very similar to the System V file system switch. They provide a layering between the generic file system activities and the file system specific activities so that you will not have to change any code in the generic layer when you want to add a new file system type. This is a part of the system that you will never have to deal with unless you are adding support for new file systems to the kernel. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
pjh@mccc.uucp (Pete Holsberg) (10/08/90)
In article <1990Oct07.121740.15280@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: =In article <1990Oct6.200834.539@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: => What are "vnodes"??? = =In a nutshell... = =Vnodes are very similar to the System V file system switch. They provide =a layering between the generic file system activities and the file system =specific activities so that you will not have to change any code in the =generic layer when you want to add a new file system type. = =This is a part of the system that you will never have to deal with unless =you are adding support for new file systems to the kernel. Thanks, Conner. I guess I had better ask the rest of the questions. :-) What is the SV file system switch? Is it true that vnodes and inodes are not at all related? Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
cpcahil@virtech.uucp (Conor P. Cahill) (10/09/90)
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
guy@auspex.auspex.com (Guy Harris) (10/10/90)
>=> 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.