Date: Mon, 02 Nov 1998 11:11:24 -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: <199811021911.LAA00716@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 02 Nov 1998 18:51:14 GMT." <199811021851.LAA01338@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I like strings *out*. > > > > > > 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? > > > 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? 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. > 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. > For a given mount attempt without an FS type specified, the > following occurs: > > > o user types "mount /dev/sd3a /mnt" > > o mount calls "fstyp /dev/sd3a" > > o fstyp calls each "/sbin/*_fstyp" until one exits non-zero > > o mount calls "/sbin/<matching fstyp>_mount" > > o /sbin/<matching fstyp>_mount calls "mount(2)" > > o If the VFS is not present in the kernel, its KLD is > demand-loaded > > o The FS is mounted. 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. > > > > > I think it is a mistake for FreeBSD to turn into Plan9. > > > > > > > > I think it's a mistake for us to make any technical decisions on > > > > emotional or us'n'them grounds. > > > > > > I'm not saying that. I'm saying that there is a recent tendency > > > to bloat in the direction of Plan9-style interfaces. > > > > ... 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'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. > > My primary agenda for string parsing is to free us from the > > chore of versioning binary interfaces (primarily with the boot code) in > > favour of using extensible string-based constructs. You'll note I've > > also been using self-describing binary structures in situations where > > they're appropriate. > > 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. > > > One could easily claim that the use of strings in sysctl is bogus, > > > and that the parsing should be to MIB identifiers, and take place > > > in user space to keep the kernel lean. > > > > 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. The issues: - Only the MIB manager knows the contents of the MIB. - 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. - 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) -- \\ 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?199811021911.LAA00716>