From owner-freebsd-net@FreeBSD.ORG  Tue Sep 30 10:25:59 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 40D1116A4B3; Tue, 30 Sep 2003 10:25:59 -0700 (PDT)
Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1ACEF4400E; Tue, 30 Sep 2003 10:25:55 -0700 (PDT)
	(envelope-from dfr@nlsystems.com)
Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2])
	by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h8UHPpFH049801;
	Tue, 30 Sep 2003 18:25:52 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8])
	h8UHPcAc097455;	Tue, 30 Sep 2003 18:25:50 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
From: Doug Rabson <dfr@nlsystems.com>
To: Bruce Evans <bde@zeta.org.au>
In-Reply-To: <20030930172536.U3713@gamplex.bde.org>
References: <20030930010128.GA31222@Odin.AC.HMC.Edu>
	 <20030930172536.U3713@gamplex.bde.org>
Content-Type: text/plain
Message-Id: <1064942737.14476.8.camel@builder02.qubesoft.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 30 Sep 2003 18:25:38 +0100
Content-Transfer-Encoding: 7bit
cc: arch@freebsd.org
cc: net@freebsd.org
Subject: Re: finishing the if.h/if_var.h split
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2003 17:25:59 -0000

On Tue, 2003-09-30 at 09:22, Bruce Evans wrote:

> That's one alternative.  (Far too) many places already use the simple
> alternative of just using "struct device *".  Grep shows 68 lines
> containing "struct device" in *.h and 32 in *.c.  For "device_t", the
> numbers are 2140 in *.h and 5089 in *.c.  This is in a sys tree with
> about 1000 matches of "device_t" in generated files.  There are non-bogus
> uses of "struct device" to avoid namespace pollution in <sys/rman.h>.
> Most other uses are just bogus (modulo the existence of device_t being
> non-bogus -- its opaqueness is negative since anything that wants to
> use it must include <sys/bus.h> and thus can see its internals.  style(9)
> says to not use negatively opaque typedefs).

The internals of struct device are not contained in <sys/bus.h> - it is
completely opaque to users outside subr_bus.c. The main 'bug' here is
the idea that its a good thing to export kernel data structures (struct
ifnet) to userland. The layout of struct ifnet is an implementation
detail - it shouldn't form part of the userland api.