From owner-freebsd-hackers Tue Oct 21 12:28:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04648 for hackers-outgoing; Tue, 21 Oct 1997 12:28:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04502 for ; Tue, 21 Oct 1997 12:25:45 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id VAA20535; Tue, 21 Oct 1997 21:24:56 +0200 (SAT) From: John Hay Message-Id: <199710211924.VAA20535@zibbi.mikom.csir.co.za> Subject: Re: FreeBSD 3.0 kernel API ?! In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from Terry Lambert at "Oct 21, 97 06:56:40 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 21:24:56 +0200 (SAT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If it's kernel code you are testing, you will need to include if_var.h > > > for it to run in the kernel; therefore you need to include if_var.h > > > for it to run in the test jig, which pretends to be the kernel. > > > > Well, you see, that's just it. It doesn't need anything else, only the > > "struct ifnet". I'd argue that a structure can be used and should be > > available anywhere, it just describes a way to store some values in > > memory. I have no problems with keeping variable names and function > > prototypes away from users (in different .h files or whatever), it > > even makes sense. But I don't think the same logic should be extended > > to structures. I assume things like struct proc and struct user are > > still available without defining KERNEL ? > > > Say I agree with you. > > How will you deal with struct ifnet when we rename all the member > variables from their current names to "opaque_variable_01" through > "opaque_variable_NN"? Even if you can depend on the structure, you > can't reasonably expect the kernel internal interface to not change. Well, I'll ask that you also fix snmpd then and keep on fixing the new versions. :-) Although it probably isn't a good example. The snmpd code is already so full of #ifdef's a few hundred more will probably not be noticed. :-) John -- John Hay -- John.Hay@mikom.csir.co.za