Date: Thu, 3 Aug 1995 11:15:07 -0400 From: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: questions@freebsd.org Subject: Re: Loadable kernel modules/filesystems Message-ID: <9508031515.AA20210@halloran-eldar.lcs.mit.edu> In-Reply-To: <9508030037.AA24090@cs.weber.edu> References: <9508021920.AA19166@halloran-eldar.lcs.mit.edu> <9508030037.AA24090@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 2 Aug 95 18:37:11 MDT, terry@cs.weber.edu (Terry Lambert) said:
>> > So i can add frogfs to the kernel and mount a frogfs file system without
>> > having to recompile my kernel or modify system header files.
>>
>> Right, you can indeed do that now.
> No, I can't. The vfssw and vfsconf arrays in kern/vfs_init.c are
> limited to MOUNT_MAXTYPE + 1 entries, and this + 1 entry is there
> soley to tag the end of the list for vfsinit() in the same file.
#undef MOUNT_MAXTYPE
#define MOUNT_MAXTYPE however_big_you_want
> The use of MOUNT_MAXTYPE+1 in fs_sysctl() in the same file is
> really broken.
You're right. Replace:
*oldlenp = (MOUNT_MAXTYPE+1) * sizeof(struct vfsconf);
with:
*oldlenp = sizeof vfsconf;
I think this is a remnant of a previous attempt on my part to only
give as an estimate the actual size of the entries that are present.
Note that slot zero is reserved; there's probably no point in copying
out the empty slot zero entry.
> In _lkm_vfs() in kern/kern_lkm.c, the index is expected to be
> specified. If the index passed in is -1 with the module, meaning
> allocate an unused slot, the module loader traverses from the
> end of the list (minus one -- MOUNT_MAXTYPE bogosity again) and
> allocates one of the "unused" slots. Unused, that is, unless
> you are using all the known file system types.
See above.
> Even if you aren't, it bogusly causes the the mount command for the
> file system type used to provide bogus arguments to the stolen slot,
Um, excuse me? Where did you get this idea? The filesystem is loaded
by the filesystem-specific mount command; it has no way of providing
any other sort of arguments.
> I won't even get into what happens with the pointer dereference
> on multiple type-specific vnodeops entries, except to say that
> only the first is handled correctly, the way that the vfs_opv_init()
> function is being called in the load.
The way that the vfs_opv_init() function is being called in the load
is functionally equivalent to the way it was called in the bad old
days when all filesystems were statically linked.
> So if I have a limited implementation, am not using a file system
> type near the end of the table and don't plan on using a file
> system type between the end of the table and the point I want
> allocated, then it *is* possible to do this in a kinda half-assed
> way.
Take your obnoxious ad-hominem arguments elsewhere, please,
Mr. Know-It-All. They are not welcome here.
> Of course, the code is the only documentation for this information.
Which is no surprise, since it was never documented anywhere.
> slot when the time cane to use it, nor leave potentially confusing
> mount_XXX mount commands able to make the mount() call but unable to
> actually perform the mout for the FS in question.
Which again is simply and utterly false, as five seconds of code
inspection would have told you if you came down from your
high-and-mighty seat and actually looked at it.
> For instance, a union mount of a read only network volume and a local
> disk for compilation of source should flag the mount as VFCF_NETWORK
> by way of inheritance.
This is an interesting idea. I'm not entirely sure I agree, but you
can certainly make a good argument for doing this.
> Probably this wants to be a flag in the mount structure that is
> inherited from the file system type(s) being mounted, potentiall
> as multiple mounts being represented as a union.
This seems entirely reasonable if you accept the premise.
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508031515.AA20210>