[Bsdbook-commit] cvs commit: bsdbook/src filesys.tex,1.1,1.2

[<dr...@us...>]

Update of /cvsroot/bsdbook/bsdbook/src
In directory usw-pr-cvs1:/tmp/cvs-serv10264

Modified Files:
	filesys.tex 
Log Message:
vfs continuation

Index: filesys.tex
===================================================================
RCS file: /cvsroot/bsdbook/bsdbook/src/filesys.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- filesys.tex	28 Aug 2002 11:02:28 -0000	1.1
+++ filesys.tex	29 Aug 2002 15:10:14 -0000	1.2
@@ -98,6 +98,11 @@
 with small fixed inode size. It should be mentioned, that this solutuion
 is used in some modern filesystem, such as linux's ext2 filesystem.
 
+User processes access a files by giving the filename. They don't care about
+the inodes. In order to convert the filename into appropriate inode,
+a special action called 'name lookup' should be done. This action is
+performed by kernel function namei().
+
 
 SUBSECTION: The superblock
 
@@ -165,6 +170,41 @@
 file size for a directory. As a result, directory sizes are never reduced.
 
 
+SUBSECTION: Userland - Kernelland interaction
+
+Now let's figure out, what happened under the hood, when user application
+issues 'open' system call in order to open a file.
+
+	o User process issues open() system call, giving the pathname and
+	desired attributes.
+
+	o System call swithes the execution mode, and now process starts to
+	execute kernel code. the open() system call hadler calls namei()
+	function to get the inode for the requested file. The namei()
+	function allocates the new inode if needed and puts it into global
+	inode table. Also a record in other system structure is made, called
+	system file table. System file table contains the records
+	of every file used by a system at the moment. Each record maintains
+	the file pointer, file access mode, and pointer to inode.
+
+	o Every process has its own file table. This is just an array of
+	pointers in U-area. Each element points to a record in system file
+	table, or is NULL. So file descriptor, returned by an open() system
+	call, is just an index in that file table. If process opens a new file,
+	it scans its file table for a NULL pointer (i.e., free slot), puts
+	the pointer to a system file table record there, and returns an index.
+	The size of file table determines the maximum number of files that
+	can be opened by a process.
+
+	o The open() system call returns and integer value which is an index
+	in the process's file table.
+
+So the file descriptor is meaningful only in the process context.
+Next, if the process issues read() or write() system call, the kernel
+will know which file to operate on by looking into process' file table and
+following the pointer indexed by a file descriptor.
+
+
 SUBSECTION: Weaknesses of s5fs filesystem
 
 
@@ -188,3 +228,62 @@
 Second is the abstraction of inode. The associated methods represent all
 the actions may have been taken over the file object.
 
+Following this architecture, the filesystem in modern UNIX OS:
+	
+	o from user point of view, is a set of files organized in
+	a hierarchical tree. Files of special types - directories - plays
+	a role of containers for the files of other types and other
+	directories. The hierarchical structure has single root,
+	and may consist of several subtrees. Each subtree is an independent
+	filesystem, and it becomes a part of a tree by performing
+	a 'mount' action. A subtree can be mounted on any directory
+	in main tree. Since those subtrees are independent, inode numbering
+	is independent in each of them.
+
+	o from user application point of view, a filesystem is a set of
+	file descriptors opened by a process. In other words, it is
+	simply an array of integers. Process may use them as parameters to
+	limited set of filesystem-related system calls such as 'open',
+	'write' etc.
+	
+	o from kernel point of view, filesystem is a list of vnodes.
+
+SUBSECTION: vnode and vnode operations
+
+So the vnode is the key element for VFS. Vnodes are fully in-memory objects,
+there are no on-disk structures associated with them. The relationship between
+vnode, in-core inode and on-disk inode is as follows:
+	vnode -> in-core inode -> on-disk inode
+Vnode is filesystem-independent object, and it 'references' the
+filesystem-dependent inode object, which is the 'copy' of appropriate on-disk
+inode object. When process requests a file, the kernel allocates new vnode
+object for that. When file is released, it deallocates the vnode object. To
+speed up those operations, the vnode cache is maintained by the kernel.
+
+One vnode is resident in kernel memory permanently: this is the vnode for
+the root of the filesystem.
+	
+
+SUBSECTION: VFS operations
+
+When a user process makes a system call that operates on filesystem in
+general, the kernel calls the appropriate VFS function. VFS function,
+naturally, points to a underlying 'real' filesystem's function.
+Here is the list of vfsops methods, and associated system calls:
+
+	Method		System Call
+
+	vfs_mount	mount
+	vfs_start	-
+	vfs_unmount	unmount
+	vfs_root	-
+	vfs_quotactl	quotactl
+	vfs_statfs	statfs
+	vfs_sync	sync	
+	vfs_vget	-
+	vfs_fhtovp	-
+	vfs_checkexp	-
+	vfs_vptofh	-
+	vfs_init	-
+	vfs_uninit	-
+	vfs_extattrctl	-