Date: Sun, 1 Nov 1998 22:25:05 +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: <199811012225.PAA28667@usr05.primenet.com> In-Reply-To: <199811012204.OAA06090@dingo.cdrom.com> from "Mike Smith" at Nov 1, 98 02:04:54 pm
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. This does *not* necessarily mean that I want the fstype name's passed into the kernel directly; rather, I'd like the integration of /sbin/fstyp, and the use of /sbin/<name>"_"<command>, using the list of returned supported types. 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. > > 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. > 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. 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. Etc.. Feel free to propose other cases, I'll be happy to discuss them. 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?199811012225.PAA28667>