Date: Tue, 21 Oct 1997 18:56:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: darrenr@cyber.com.au (Darren Reed) Cc: tlambert@primenet.com, darrenr@cyber.com.au, hackers@freebsd.org Subject: Re: FreeBSD 3.0 kernel API ?! Message-ID: <199710211856.LAA13887@usr04.primenet.com> In-Reply-To: <199710210218.MAA11955@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 12:18:59 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. > > I think the issue is maybe that your test environment doesn't look > > sufficiently like a kernel... > > No, it doesn't. Given that malloc(3) doesn't quite grok M_WAITOK, > probably never will :-) Setting aside for the moment that your test malloc whould grok M_NOWAIT, and your code meant to run in the kernel should not be referencing the malloc(3) function in the first place... What exactly are you expecting to be able to test? Certainly, you can't test any of the interfaces that implement struct ifnet type derived parameters, and certainly you can't test race windows and spl issues triggered by a malloc(..., M_NOWAIT) returning a failed (NULL) allocation, etc.. I think your test case may be a bit contrived to justify your wanting to access the internal structure. 8-|. 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?199710211856.LAA13887>