Hy, The current description was tagged as of kernel 2.1.99 - so whatever story I'll write here should be more truthful than that fossil ;-)
Stone:/usr/src # diff -r -u linux-2.6.13-rc1.UNTOUCHED linux-2.6.13-rc1 ------------------------------SNIPON----------------------------------- diff -r -u linux-2.6.13-rc1.UNTOUCHED/Documentation/filesystems/vfs.txt linux-2.6.13-rc1/Documentation/filesystems/vfs.txt --- linux-2.6.13-rc1.UNTOUCHED/Documentation/filesystems/vfs.txt 2005-06-30 01:00:53.000000000 +0200 +++ linux-2.6.13-rc1/Documentation/filesystems/vfs.txt 2005-07-06 03:36:23.000000000 +0200 @@ -126,46 +126,53 @@ struct file_system_type <section> ======================= -This describes the filesystem. As of kernel 2.1.99, the following +This describes the filesystem. As of kernel 2.6.13, the following members are defined: struct file_system_type { - const char *name; - int fs_flags; - struct super_block *(*read_super) (struct super_block *, void *, int); - struct file_system_type * next; -}; - - name: the name of the filesystem type, such as "ext2", "iso9660", - "msdos" and so on - - fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) - - read_super: the method to call when a new instance of this - filesystem should be mounted - - next: for internal VFS use: you should initialise this to NULL - -The read_super() method has the following arguments: - - struct super_block *sb: the superblock structure. This is partially - initialised by the VFS and the rest must be initialised by the - read_super() method - - void *data: arbitrary mount options, usually comes as an ASCII - string + const char *name; + int fs_flags; + struct super_block *(*get_sb) + (struct file_system_type *, int, const char *, void *); + void (*kill_sb) (struct super_block *); + struct module *owner; + struct file_system_type * next; + struct list_head fs_supers; + }; + + name: The name of the filesystem type, such as "ext2", "iso9660", + "msdos" and so on. + + fs_flags: A combination of: FS_REQUIRES_DEV, FS_BINARY_MOUNTDATA, + FS_REVAL_DOT, FS_ODD_RENAME (deprecated). See include/linux/fs.h. + + get_sb: The function responsible for returning the super_block structure + containing the filesystems blocksize, it's super block, + super operations struct s_op (which is the most interesting field + filled by this method and a pointer to struct super_operations + which describes the next level of the filesystem implementation), + the magic byte and max filesize and the like. + It is called when a new instance of this filesystem is mounted and + replaces the read_super function of former kernels (see porting). + As an example of what to do here please look at one of the default + functions in the kernel code named 'get_sb_nodev'. + The get_sb_nodev functions last parameter is a pointer to a function + which would act like the former read_super function just mentioned. + The data parameter contains arbitrary mount options passed by the + unix mount program, it usually comes as an ASCII string but can + be set to come as binary (now please don't ask me where I saw this + flag, look at the source, Mr. Skywalker ;-). + Return value: New super block on success, ERR_PTR if failed. + + kill_sb: the function which gets called when the sb needs to be destroyed. + One generic function for this is 'kill_anon_super', look there for + more inspiration. - int silent: whether or not to be silent on error + owner: This is usually set to the macro 'THIS_MODULE'. -The read_super() method must determine if the block device specified -in the superblock contains a filesystem of the type the method -supports. On success the method returns the superblock pointer, on -failure it returns NULL. + next: Managed by the kernel. Please leave it as NULL. -The most interesting member of the superblock structure that the -read_super() method fills in is the "s_op" field. This is a pointer to -a "struct super_operations" which describes the next level of the -filesystem implementation. + fs_supers: Managed by the kernel. Please leave it as NULL. struct super_operations <section> ------------------------------SNIPOFF---------------------------------- Stone:/usr/src # -- Thanks, Frank Schruefer SITEFORUM Software Europe GmbH Germany (Thuringia) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/