Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.arcetri.astro.it/irlab/doc/library/linux/khg/HyperNews/get/fs/vfstour/1.html
Дата изменения: Thu Mar 23 12:37:34 2000
Дата индексирования: Wed Sep 15 04:09:24 2010
Кодировка:

Поисковые слова: m 2
A couple of comments and corrections The HyperNews Linux KHG Discussion Pages

Feedback: A couple of comments and corrections

Forum: A tour of the Linux VFS
Keywords: comments, correction, implementation details
Date: Thu, 23 May 1996 03:20:42 GMT
From: Jeremy Fitzhardinge <jeremy@zip.com.au>

A minor point: binfmt_java only deals with Java class files,
not JavaScript (which is unrelated to Java in all but name).

In general it looks OK, but it doesn't really talk about the
distinction between file operation and inode operations (or
the distinction between struct file and struct inode).

Inodes represent entities on disks: there's one (and only one)
for each file, directory, symlink, device and FIFO on the
filesystem.

When a user process does an open() syscall, it does a couple
of things:
	- it looks up the inode for the pathname
	- it puts the inode into the inode cache
	- it allocates a new file structure
	- it allocates a filedescriptor slot, and points it
	  it at the file structure

The number of the file descriptor slot is what is returned.

The distinction is subtle but important.  Inodes have no
notion of "current offset": that's in the file structure,
so one inode can have many file structures, each at a
different offset and mode (RO/WO/RW/append).  If you use
the dup() syscall, you can have multiple file descriptors
pointing to the same file structure (so they share their
offsets and open modes).

What this means for a filesystem is that you rarely need
to implement the open() file operation, unless you actually
care about specific file open and close operations.  However,
you must always implement iget() operations.

I guess there's lots more that can go here:
	- interaction with the VM system and page cache
	- coping with dynamic filesystems (filesystems who's
	  contents change of their own accord)
	- structure of a Unix filesystem (inodes/names/links)
	- what order to do things in, and how the various
	  VFS calls interact
	- documenting the args of the VFS interface functions

I know this is supposed to be documentation, but the kernel
source is a good place to look...

[Plug mode] A good way of finding out about how Linux
filesystems work is Userfs, which allows you to write user
processes which implement filesystems.  It has a readme
which talks in some detail about how to implement filesystems,
which is somewhat applicable to writing kernel resident
filesystems too.  It's available at
tsx-11.mit.edu:pub/linux/ALPHA/userfs.  The structure of
the userfs kernel module is also a pretty good guide for
a skeletal filesystem.

	J