From owner-freebsd-questions Tue Aug 1 16:45:25 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id QAA14447 for questions-outgoing; Tue, 1 Aug 1995 16:45:25 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id QAA14437 for ; Tue, 1 Aug 1995 16:45:24 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA05600; Tue, 1 Aug 95 17:36:01 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508012336.AA05600@cs.weber.edu> Subject: Re: Loadable kernel modules/filesystems To: nik@blueberry.co.uk (Nik Clayton) Date: Tue, 1 Aug 95 17:36:00 MDT Cc: questions@freebsd.org In-Reply-To: <199508011308.NAA01479@elbereth.blueberry.co.uk> from "Nik Clayton" at Aug 1, 95 01:08:52 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@freebsd.org Precedence: bulk > However, lkm(4) says > > Virtual File System modules > Virtual file systems may be added via the LKM interface. At this > time, only file systems which are already known to the system can > be added, because of the way the mount(2) system call is imple- > mented. > > which seems to contradict my hypothesis above. > > Anyone got the straight dope on this? The mount system call code takes a manifest constant specifying file system type; this constant is defined in mount.h. The manifest constant is used as a table index to look up the file system type. This is why the man page says this; unless there is a pre-reserved slot, there would be no way for mount to identify the file system type and then make the appropriate call, since there would be no way to determine the manifest constant to use in the mount system call as the file system type index. So "known" in this context means "manifest constant in mount.h". The appropriate fix for this is to get the file system type by name and pass that to the kernel to have it mapped to a table location. Probably via linear search, since it's not a common operation and occurs only as a result of administrative fiat. There's already an interface to lookup by name; the missing piece is is passing a name instead of a constant over the mount layer and some changes to table lookup, organization, and dead entry identification. If you wanted to get fancy, you'd provide a user level fstyp mechanism similar to the one in SVR4 to identify file system type from device contents (usually superblock). Then calling mount would automatically pick the right mount command and "just work". There is a partial code cleanup of the mountroot warts in my account on freefall. The CD9600 and NFS code still need cleanup in this regard, and then the device mapping for the root device needs to move to the vfs_mountroot routine (which I've put in kern/vfs_conf.c). Really, it wants file systems to be described with a flags descriptor so that you can know whether a file system is local or remote, or the vfsops structure needs those flags. That would allow it to format FS type specific by class instead of by FS. The NFS is the big worry here; the CD9660 stuff is really very warty in that it should be able to identify file system types rather than needing them passed in via flags. I didn't do the NFS cleanup or the full i386/i386/autoconf.c cleanup because of the CD9660 cruft, mostly because I don't have a big enough CDROM collection to warrant that the autodetect code would work (Jordan or someone needs to take that code and fix it). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.