From owner-freebsd-hackers Mon Oct 20 18:32:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06906 for hackers-outgoing; Mon, 20 Oct 1997 18:32:53 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06883 for ; Mon, 20 Oct 1997 18:32:36 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.7/8.8.5) id SAA08273; Mon, 20 Oct 1997 18:31:25 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd008268; Mon Oct 20 18:31:23 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA24304; Mon, 20 Oct 1997 18:31:21 -0700 (MST) From: Terry Lambert Message-Id: <199710210131.SAA24304@usr08.primenet.com> Subject: Re: FreeBSD 3.0 kernel API ?! To: darrenr@cyber.com.au (Darren Reed) Date: Tue, 21 Oct 1997 01:31:21 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: <199710210054.KAA09620@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 10:54:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hmmm, I think that duplicate functionality has some merit. For one, > it allows you to migrate from old to new rather than having to choose - > providing that it is posible to have both in a sane way. So whilst > the old functionality will not be available in the future, you can > use the old one whilst you refit to use the new one. This is the Novell NetWare API problem. If I have an old interface and a new interface, I will choose to use the old interface. Why? Because it's the larger market: my code will run on both old and new. If I used the new interface, I'd only be able to run on new. The market "old + new" > the market "old". Simple economics. > > 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. 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. I think the issue is maybe that your test environment doesn't look sufficiently like a kernel... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.