Date: Sun, 01 Nov 1998 16:20:08 -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: <199811020020.QAA06721@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 01 Nov 1998 22:25:05 GMT." <199811012225.PAA28667@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811020020.QAA06721>