Date: Tue, 21 Oct 1997 21:24:56 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: tlambert@primenet.com (Terry Lambert) Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 3.0 kernel API ?! Message-ID: <199710211924.VAA20535@zibbi.mikom.csir.co.za> In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from Terry Lambert at "Oct 21, 97 06:56:40 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710211924.VAA20535>