Date: Fri, 5 Jun 1998 12:00:34 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: dufault@hda.com (Peter Dufault) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... Message-ID: <199806051700.MAA00911@dyson.iquest.net> In-Reply-To: <199806051116.HAA04969@hda.hda.com> from Peter Dufault at "Jun 5, 98 07:16:14 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Dufault said: > > echo "0" >/kernfs/net/inet/tcp/rfc1323 > > > > It is entirely bogus for the kernel to parse strings like this. We > > probably do it, but that doesn't mean it's right... Even worse would be: > > Sorry, "entirely bogus" is just too strong for me - I think this > should be "entirely irrelevant". > > I have 48K microcontroller systems that you can hook up a terminal > too, hit CR six times "out of band", and they pop out of the usual > binary protocol into a mode where they can be configured in ASCII > (the ASCII is parsed into the binary protocol). If I can afford > the overhead for parsing there we can afford the overhead in the > kernel. > > The point is, I don't care if it is in the kernel or out of the > kernel if it is designed in a way that it could be in either place. > My argument is so vehement partially due to locale issues. Since we have a userland, and the ability to put things in user-mode, it seems to make little sense to burden the kernel unnecessarily. This is a slipperly slope thing, and we need to recogize that if the kernel presents an interface, we shouldn't depend on binary to ascii conversion in the kernel, or blind binary either. We should present both the data and the format of the data between the kernel and user mode. User mode can then split the data effectively. The exposure of /dev/kmem is an example of parsing varying, unformatted data. Formatting in ascii doesn't really help either, because it puts both the formatting load onto the kernel, and ALSO the higher level data format is still blind. This is NOT an all or nothing deal, but just providing a filesystem interface to something that already has both an interface and data interpreter is a backwards step. Our sysctl is not ideal or finished, but does architecturally provide the interface and data interpreter. I don't care how this thing is done, and the code (or mechanism) appears to be an orphan. We have done some good work on sysctl (it is really easy to use, as opposed to the original stuff as seen on other *BSD's), but it does need more work. If embarking on a pseudo-better /kernfs, I don't want to see a regression, but a progression -- otherwise we'll still have two interfaces. I suggest that the best efforts would be to complete the sysctl interface, so that we don't have to reinvent so much. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. 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?199806051700.MAA00911>