From owner-freebsd-hackers Mon Oct 20 16:58:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00117 for hackers-outgoing; Mon, 20 Oct 1997 16:58:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00111 for ; Mon, 20 Oct 1997 16:58:14 -0700 (PDT) (envelope-from darrenr@cyber.com.au) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id JAA09206; Tue, 21 Oct 1997 09:57:17 +1000 From: Darren Reed Message-Id: <199710202357.JAA09206@plum.cyber.com.au> Subject: FreeBSD 3.0 kernel API ?! To: tlambert@primenet.com (Terry Lambert) Date: Tue, 21 Oct 1997 09:57:17 +1000 (EST) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199710201834.LAA09783@usr05.primenet.com> from "Terry Lambert" at Oct 20, 97 06:34:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail I received from Terry Lambert, sie wrote > > > > If the code isn't portable to Linux, SVR4, and Solaris without > > > compile time switches, why write it? > > > > Well, prior to these changes to FreeBSD, it was portable between > > *BSD/SunOS4/Solaris2 without any compile time switches - not sure > > about Linux. Why ? Because up until recently, all would give > > you "struct ifnet" if you included net/if.h. > > > > So there you have it. > > > > This makes it harder to port code to FreeBSD. > > > > Or, from the other angle, FreeBSD code is less portable. > > > > Isn't that just wonderful ? *spew* > > It seems your complaint is that the use of the struct ifnet in > the internal structures is not bracketed by: > > #ifdef __IF_VAR_H__ > #endif No, it isn't. > If you are using structures that contain this opaque data object, > then you are doing something wrong. > This is not to say that I'm happy with the code (I'm not), but > that this type of interface seperation is both (1) necessary, and > (2) desirable, from a "pure environment" perspective. Sigh. This is all very amusing, I guess. Here's a tip for you: if you *really* want to separate what user programs can and can not include (or should and should not), don't put any "kernel only" include files under /usr/include and remove all references from /usr/include files to anything that should only be in the kernel. Sure, you'll break lots of software out there, be totally incompatible with everything else and annoy lots of 3rd party software writers, but it _will_ achieve the goal you're aiming for: - penalising anyone and everyone who makes use of a kernel structure for non-kernel code, irrespective of its use. Personally, I don't think any changes should be made for the sake of making a change to hide structures but rather, effort should be put into developing useful interfaces which software can take advantage of. Darren p.s. what's up with hackers@freebsd ? I haven't seen any mail come through it for a while now...