A couple of comments and corrections|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: 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 Кодировка: Поисковые слова: п п п п п п п р п |
A couple of comments and corrections
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 |