From owner-freebsd-hackers Mon Nov 2 10:51:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17919 for freebsd-hackers-outgoing; Mon, 2 Nov 1998 10:51:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17911 for ; Mon, 2 Nov 1998 10:51:35 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA16141; Mon, 2 Nov 1998 11:51:28 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd016103; Mon Nov 2 11:51:20 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA01338; Mon, 2 Nov 1998 11:51:14 -0700 (MST) From: Terry Lambert Message-Id: <199811021851.LAA01338@usr05.primenet.com> Subject: Re: scanf in the kernel? To: mike@smith.net.au (Mike Smith) Date: Mon, 2 Nov 1998 18:51:14 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199811020020.QAA06721@dingo.cdrom.com> from "Mike Smith" at Nov 1, 98 04:20:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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/_mount" o /sbin/_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