Date: Tue, 21 Oct 1997 00:11:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: darrenr@cyber.com.au (Darren Reed) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: FreeBSD 3.0 kernel API ?! Message-ID: <199710210011.RAA28373@usr05.primenet.com> In-Reply-To: <199710202357.JAA09206@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 09:57:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Sigh. This is all very amusing, I guess. Here's a tip for you: > if you *really* want to separate what user programs can and can not > include (or should and should not), don't put any "kernel only" > include files under /usr/include and remove all references from > /usr/include files to anything that should only be in the kernel. The idea, I believe, is to clean up our own misuse of KVM as a non-procedural interface to kernel data. Non-procedural interfaces are bad because: 1) You can't hook them 2) A data version change equals an interface change, and requires you to rebuild everything that references the data 3) You can't "version" the interface so that the program using it can operate against both old and new versions. > Sure, you'll break lots of software out there, be totally > incompatible with everything else and annoy lots of 3rd party > software writers, but it _will_ achieve the goal you're aiming > for: - penalising anyone and everyone who makes use of a kernel > structure for non-kernel code, irrespective of its use. The only thing we intended to break was ourselves, because we knew we were engaging in bad programming habits. It's only your poor fortune to have *also* been engaging in bad programming habits. > Personally, I don't think any changes should be made for the > sake of making a change to hide structures but rather, effort > should be put into developing useful interfaces which software > can take advantage of. I agree. But how can we get a picture of the spanning set of new interfaces needed unless we take away all of the old interfaces, and log what fails? Sure, we could organically grow things, and let duplicate functionality (say like /procfs and sysinit) creep up on us, so that we can't really point at "here is the right way", but do we really want that? Brass tacks time: Why do *you, personally* need the kernel internal structure defined by struct ifnet? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710210011.RAA28373>