Date: Tue, 3 Nov 1998 17:53:05 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: scanf in the kernel? Message-ID: <199811031753.KAA29906@usr05.primenet.com> In-Reply-To: <199811021911.LAA00716@dingo.cdrom.com> from "Mike Smith" at Nov 2, 98 11:11:24 am
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. > > > > 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. > 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. > > 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. [ ... 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. > > > ... 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". You aren't required to consider my opinions, but I'm likewise not required to not offer them if I think you are going down the wrong primrose path. > > > You're the one agonising over passing data across the user/kernel > > > boundary. > > > > Yes, I am. Every time I have to recompile libkvm and ps, w, finger, > > netstat, etc., etc., I agonize over the externalization of kernel > > internal data as defacto interfaces. > > You're facing the wrong way. Using self-describing and robust > interface formats reduces the need for this. At the moment, the > biggest problems faced by the above tools is that they depend on > manifest constants and implicit structure definitions. None of this > will be helped by your stance. Nor will it be helped by bloating the kernel before you address the existing problems. > > They are apropriate anywhere their data is externalized directly > > instead of procedurally (an FS is a good place to convert data > > references into procedural references, if you need that sort of > > thing, hence procfs). > > Yes; I'm actually teaching myself about the VFS model by writing what > I've grandly called metafs, which aims to be a framework into which > various non-file-objects can register themselves in order to appear as > a filesystem. The major design flaws with both procfs and kernfs are > that they are essentially static. The original goal was to produce an > emulation of the linux procfs, however it became clear that I needed to > understand the VFS framework and provide infrastructure for the many > pieces of junk they aggregate there. 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. > > > This might have been fine when the MIB was a static object produced at > > > compile time. As an approach for name translation in a dynamic tree > > > it's simply not workable. > > > > So basically, you are denying the reality of IBM's SNMPv2 implementation, > > which allows dynamic (de/)registration of manageable hierarchies of > > exposed data? > > > > I have to say, having used the reference implementation 4 years ago > > on Solaris, I don't think that it has quit working in the interim... > > There is no information here. I can't read your mind. IBM's SNMPv2 implementation performs name translation in a dynamic tree. > The issues: > > - Only the MIB manager knows the contents of the MIB. IBM's SNMPv2 implementation allows registration of subregions into the MIB by the servers responsible and requring the subregions. As a result, it is dynamic, yet maps precisely, at all time, the current content and configuration requirements. > - Objects are added to the MIB via the MIB manager. > - Only the object provider knows what the object is. > - Objects may be renumbered at effectively arbitrary times. IBM's SNMPv2 implementation is, effectively, a streams MUX. It is relatively trivial to convert from such an implementation to a shared object implementation or a shared memory implementation or a UNIX domain socket implemetnation, etc.. This means: - Objects are added to the MIB by the instancer of the objects, and only procedurally exposed through the MIB manager, instead of being directly exposed through the MIB manager. - Only the objct provider *need* to know what the object is. - Objects may be renumbered at effectively arbitrary times, but this has no impact on the object implementation or th implementation of a management interface, if the management interface is abstracted via addition MIB contents. > - We don't have a predefined list of all the possible objects. > > 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199811031753.KAA29906>