Date: Wed, 26 Mar 1997 14:03:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sommerfeld@orchard.east-arlington.ma.us (Bill Sommerfeld) Cc: jonathan@dsg.stanford.edu, terry@lambert.org, perry@piermont.com, hackers@freebsd.org, port-i386@netbsd.org Subject: Re: how to name fs specific programs Message-ID: <199703262103.OAA28602@phaeton.artisoft.com> In-Reply-To: <199703261426.OAA10034@orchard.east-arlington.ma.us> from "Bill Sommerfeld" at Mar 26, 97 09:26:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I believe I understand what Terry's suggesting. > > He wants to be able to be able to have a new filesystem type appear by > simply mounting (or symlinking, or copying) the implementation of a > new filesystem type into /sbin/fs/foo, and he believes that the name > of the filesystem type should be defined purely by the name used in > the /sbin/fs directory, and not by anything inherent in the binaries > found inside /sbin/fs/foo/. Yes. > so that, as an extreme case, one could do > mv /sbin/fs/{nfs,losefs} > and > sed 's/nfs/losefs/' </etc/fstab >/etc/fstab.NEW && mv /etc/fstab{.NEW,} > > and reboot, and everything will keep working.. Or, a more extreme case: cp -R xxxfs /sbin/fs newfs -T xxx /dev/rfd0a mount /dev/fd0a /mnt and not even reboot, since one of the binaries that gets moved might be named "lkm"... a kernel module implementing the FS type, which is demand loaded by the kernel as a result of the typed mount request (all mount requests are typed because the generic "mount" which invokes them calls the generic "fstyp", which calls each available FS's "fstyp" to identify the FS and make the typed mount request). I'd actually *prefer* that the per FS kernel code modules be implemented in the same component as the user space FS support commands, when you get down to it. Here are some other scenarios; each assumes additional work on kernel modularity and component-based implementation of FS modules (but the same ideas can be spread to non-FS module types as well): Case 1: Consider the agregator (generic) "mount", whose purpose is to agregate all of the FS-specific "mount" commands into itself. # ls -F /sbin/mount /sbin/mount@ # ls -L /sbin/mount /fs/mount So the mount command in /sbin is a link to the file /fs/mount. By default, all the commands in /fs are specific to a single FS type; for example, FFS. So in the "only / mounted" case, /fs/mount is the FFS mount command. Now we want to load other FS type capabilities into the system. To do this, we mount over /fs. We will ignore the details of loopback and overlay mounting to "move" the contents of "/fs" to allow them to be accessable without duplicating them. We simply note that it is possible to do this. The mounted-over "/fs" now contains: /fs/mount <- an agregator (generic) mount /fs/ffs/mount <- FFS specific mount, the former /fs/mount /fs/*/mount <- other FS specific mounts for FS types that are also supported not that /fs is mounted over The mount requests for FFS still go to /sbin/mount (/fs/mount). It's not really important whether the "/fs" is "/fs" or an "fs" subdirectory of /sbin (or wherever). What's important is that the "sub-directory of fs" implementation allows file systems to be treated as seperate components. Case 2: Consider that the kernel can be an ELF or other section-level attributable binary file format. Posit that the final stage boot loader has been modified to load some section tags from the image and not others. The act of loading a section with a "module" tag invokes the module registration mechanism. Now there is no difference between an FS LKM and an FS module, other than the ELF file of which the section is a member. To build a kernel which will load and run on EXT2FS formatted devices, we use a section archiver to remove the FFS module section and insert an EXT2FS module section in its place. We do not relink the kernel. We could insert both the FFS and EXT2FS modules simultaneously, if we didn't care about burning the space on the boot media or in the VM image. Since the FFS is not needed for boot, however, we can provide FFS support later using an overlay mount (as in Case 1). We now have a minimal kernel localized to the root FS type. And we have done it without the USL/SVR4 "hack" of having a "bootfs" FS type. Case 3: Because we have segment level tagging for unloaded-by-boot segments in our kernel image, we can treat any unloaded segment as an FS in it's own right, as long as the kernel can still access the kernel image contents (we probably want this anyway to support kernel paging, and it's not a lot of work to do). Now we may treat the kernel image as an FS in its own right; an MFS with the kernel image as backing store, if nothing else. We may mount a section as /fs. This section is one of the sections in the FS module which we added for the root FS support. Just as with devfs, we now have an FS name space entry, only instead of being for "/dev", it's for "/fs" at boot time, and is later mounted on "/fs/ffs" (or whichever FS type the root FS is). Alternately, the kernel would also contain the agregators -- a "/fs" FS whose purpose is to allow the mounting of other inferior per-FS directories and provide agregators for all later FS modules. Since the images (other than root, which contains the kernel) are swappable, they don't actually take up VM, so this is not as much of a memory hog as it might seem. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703262103.OAA28602>