Date: Tue, 03 Nov 1998 12:54:22 -0800 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: scanf in the kernel? Message-ID: <199811032054.MAA00380@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 03 Nov 1998 17:53:05 GMT." <199811031753.KAA29906@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > I believe the "last time" to which you refer is the mount fstype > > > > > argument, in which I thought it was stupid to limit yourself to > > > > > defined FS's in mount.h. > > > > > > > > So you want more binary clutter and interface dependency just to > > > > translate FSNAME to FSNUMBER? > > > > > > Given a choice between user space bloat and kernel bloat, I choose > > > user space bloat. > > > > And given the opportunity to trade large user-space bloat and > > management headaches for miniscule kernel bloat? > > It's only a management headache if you insist on micro-managing > the kernel. Most of the sysctl tunables in the kernel shouldn't be. It's a management headache because it's a collection of components which can (and will) go stale, maintained without any infrastructure. > > > > > So installing a new FS type installs commands in /sbin, and hving > > > > > installed commands in /sbin, the list is known via a traversal of > > > > > sbin, without even asking the kernel. > > > > > > > > Er. And who do you ask to do the traversal of /sbin? > > > > > > In the limit, /sbin/fstyp. > > > > And what does it use? > > It goes out and reads the raw partition to determine the format. No, it uses the kernel to perform the traversal of the /sbin namespace. I don't see anything logically different here to the kernel doing its own traversal internally. > > You're overloading the filesystem namespace to perform a translation > > from FSNAME to FSNUMBER, using an inefficient interface with no > > guarantee that the translation space is representative of the state of > > the kernel. > > That's a first revision. > > The second revision replaces /sbin/nfs_mount with /libexec/fs/nfs.so. > > The third revision asks the kernel to page in all non-resident VFS's > identification routines from their seperate ELF sections in the > respective VFS drivers on a device arrival event, and mounts the > FS automatically based on the contents of the "last mounted on" > string, as long as the "don't automount me" bit isn't set. ... which is where we're heading. > > > > This is not an ideal soloution, but consider that the VFS KLD(s) > > > for a given filesystem may not be in the kernel. > > > > Of course I've considered that. By passing in an arbitrary key string > > for the VFS type, you have a direct translation to a module filename, > > which you can demand load in a transparent fashion, rather than > > requiring an error return, user-space module load and recall. > > Well, that's obvious, but paging that portion of the kernel not > in the paging path, and treating KLD's a nothing more than backing > store for kernel pages is even more obvious. There's no guarantee that KLDs will be writable as backing store; you'd have to handle paging them to anonymous space too. > > [ ... mounting ... ] > > > Fine. None of this has anything to do with passing the key over the > > user:kernel boundary, which you do in the mount phase in order to > > reliably locate the module responsible for the VFS. > > Which was exactly the point of the exercise: to show that key passing > is not necessary to implement the code. It's necessary to pass *something* in the current toploaded architecture. Until we have the SLICE infrastructure back, there's no viable alternative (fstyp is a bad joke). > > > > ... and you're attaching an implicit value judgement to that "tendency". > > > > > > Actually, I was quite explicit: > > > > > > I think it is a mistake for FreeBSD to turn into Plan9. > > > > > > And with the "I think" in there, it's obviously an opinion. But it's > > > an opinion based on experience, not emotion. > > > > It's an implicit opinion, offered with no justification other than an > > other implicit "you should trust me (because I'm a loud dog)". > > You've interpreted this wrong. My intent was to state "You should > consider the ultimate consequences of your design decisions before > you make them" and "I think this design decision is ill considered". I know. This is why I said you were making an implicit value judgement. > Well, I certainly can't disagree with this direction. I think it's > the right way to go for most of the MIB data that's in sysctl. If > you need a scanf for that, then by all means, it should be part of > that VFS module. No. It should be a general kernel service so that we don't bloat every module that might want to use it with a private copy. > > Tell me how you plan to export the mapping between MIB numbers and > > names from the MIB manager. Tell me how this is not a name-to-number > > lookup interface. 8) > > By looking up the names in a different part of the MIB. Which is a name-to-number translation interface. Provided by the mib manager group entity. Thank you for at last agreeing. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811032054.MAA00380>