> 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.