Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Aug 95 17:36:00 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        nik@blueberry.co.uk (Nik Clayton)
Cc:        questions@freebsd.org
Subject:   Re: Loadable kernel modules/filesystems
Message-ID:  <9508012336.AA05600@cs.weber.edu>
In-Reply-To: <199508011308.NAA01479@elbereth.blueberry.co.uk> from "Nik Clayton" at Aug 1, 95 01:08:52 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508012336.AA05600>