Date: Tue, 21 Oct 1997 12:18:59 +1000 (EST) From: Darren Reed <darrenr@cyber.com.au> To: tlambert@primenet.com (Terry Lambert) Cc: darrenr@cyber.com.au, hackers@freebsd.org Subject: Re: FreeBSD 3.0 kernel API ?! Message-ID: <199710210218.MAA11955@plum.cyber.com.au> In-Reply-To: <199710210131.SAA24304@usr08.primenet.com> from "Terry Lambert" at Oct 21, 97 01:31:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail I received from Terry Lambert, sie wrote > > > > Brass tacks time: > > > > > > Why do *you, personally* need the kernel internal structure > > > defined by struct ifnet? > > > > Because I try to use the same code for compiling into the kernel > > as into the testing code. If I have to fake struct ifnet, I'll > > only end up building a structure which has the same fields anyway. > > Even though things like if_output aren't going to call the same > > device driver output routine, I can use it to write to a file > > and verify what's getting written out. > > I still don't understand. If it is kernel code, even if you plan on > running it in user space, you will define KERNEL. If you don't you > are not testing the code you will be running. There are a couple of things lacking from the typical libc that are in kernels. Things like mbuf functions, etc. > 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 ? > 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 :-) Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710210218.MAA11955>