Date: Mon, 2 Nov 1998 18:51:14 +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: <199811021851.LAA01338@usr05.primenet.com> In-Reply-To: <199811020020.QAA06721@dingo.cdrom.com> from "Mike Smith" at Nov 1, 98 04:20:08 pm
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. > > 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. This is not an ideal soloution, but consider that the VFS KLD(s) for a given filesystem may not be in the kernel. 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. > > > > 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. > 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. > 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). > > 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... 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?199811021851.LAA01338>