From owner-freebsd-hackers Tue Oct 21 20:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01345 for hackers-outgoing; Tue, 21 Oct 1997 20:34:24 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01339 for ; Tue, 21 Oct 1997 20:34:22 -0700 (PDT) (envelope-from sef@Kithrup.COM) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id UAA23820; Tue, 21 Oct 1997 20:34:20 -0700 (PDT) Date: Tue, 21 Oct 1997 20:34:20 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199710220334.UAA23820@kithrup.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org Subject: Re: FreeBSD 3.0 kernel API ?! In-Reply-To: <199710220202.MAA01643.kithrup.freebsd.hackers@plum.cyber.com.au> References: <199710211856.LAA13887@usr04.primenet.com> from "Terry Lambert" at Oct 21, 97 06:56:40 pm Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 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. >This sort of change I think is, to put it bluntly, fucked. Terry's problem is that he is forgetting that non-kernel bits are part of the OS in unix. This means that some non-kernel bits have to know the format (and location) of some kernel data structures, sometimes. (While there are many cases where you can abstract this into a usable API, there are many other cases where you can't -- because what you want to get at is, indeed, exactly what the kernel is using.) This is further complicated by the fact that some utilities people have decided are part of the OS are not maintained by us. Ah, well. Reply to me, or the list, but not both, please.