From owner-freebsd-hackers Sun Nov 1 16:21:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04680 for freebsd-hackers-outgoing; Sun, 1 Nov 1998 16:21:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles33.castles.com [208.214.165.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04671 for ; Sun, 1 Nov 1998 16:21:14 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA06721; Sun, 1 Nov 1998 16:20:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811020020.QAA06721@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: scanf in the kernel? In-reply-to: Your message of "Sun, 01 Nov 1998 22:25:05 GMT." <199811012225.PAA28667@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 16:20:08 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > In general, the only place strings should probably be used in the > > > kernel at all are in filesystem namespace exposures. > > > > You're internally inconsistent. Last time you decided you liked > > strings over manifest constants. > > 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? > 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? > > > 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". > > There are instances where it's clearly useful to be able to process > > string format data (eg. the SCSI quirk code). The necessity for this > > combined with the lack of formal string parsing has led to the > > implementation of any number of ad-hoc solutions. If you want to argue > > for the removal of all string processing in the kernel, you need to > > explain how all of these existing functions are going to work. > > I'll be happy to address the architectural issues on a case-by-case > basis, to any level of detail you want. > > One does wonder how you would boot from a "quirked" drive if you > had to allow pushing the data over the user/kernel boundary to > be able to recognize the quirks. You're the one agonising over passing data across the user/kernel boundary. 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. > 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. -- \\ 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