From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 08:08:38 2003 Return-Path: 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 EA93816A4B3; Tue, 30 Sep 2003 08:08:38 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8529744017; Tue, 30 Sep 2003 08:08:37 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8UF8YOP011375; Tue, 30 Sep 2003 17:08:35 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Sep 2003 10:33:48 EDT." Date: Tue, 30 Sep 2003 17:08:34 +0200 Message-ID: <11374.1064934514@critter.freebsd.dk> cc: arch@FreeBSD.org cc: net@FreeBSD.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 15:08:39 -0000 In message , John Baldwin writes: >>>Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover it >>>sounds a good idea to have the if_dev field into the ifnet structure. >> >> Somebody please explain how this would work for non-hardware >> interfaces like if_loop, if_tun, if_tap etc ? >> >> device_t is what we use to hitch drivers to hardware. >> >> ifnet is what we use to hitch drivers to the netstack. >> >> They should not be tangled. > >You mean like dev_t and device_t shouldn't be tangled like we do >with si_drv1? Oh, wait... I don't think any correctly written driver stores it's device_t in a dev_t. It should store it's softc structure, which should contain pointers to both. Even if there is a driver which does do that, it happens inside the device driver, and it does not handicap the remaining device drivers with its choice. If you stick a newbus requirement on "struct ifnet" you suddenly make demands that a lot of our network drivers cannot satisfy. The problem with propagating newbus above the device drivers is that we start postulating a specific relationship between logical devices and physical (ie: a ifnet has exactly one device_t). There is nothing in the "data-model" of the kernel that says that a network interface corresponds to exactly one hardware device and more importantly: there shouldn't be either. If_tun _has_ no physical device, and it would be totally insane to invent a device_t for if_tun, considering that it would not serve any purpose at all, apart from satisfying some peoples craving to have device_t in all data structures in the system. Demanding such a relationship will only make our life more difficult when we get to deal with all the non-standard devices like if_sl, if_ppp, if_ng, if_tun, if_tap which have no device_t, or musycc, a network card where you have to juggle two device_t's, one for the framer and one for the line encoder. As it is now, device_t and newbus provides a good model for our attachment of device drivers to hardware, it's not quite perfect, but it is good enough that nobody can be bothered to sit down and write something perfect. We have "struct ifnet" which describes a network interface, it describes it based on the access model, and it does in fact not care a hoot what implements that interface, hardware, software or bongo drums, it doesn't matter. Similarly, we have "dev_t" to descripe filesystem accessed devices, and it describes those in the terms of the access model, not in terms of what is behind them, hardware, software or bongo drums. If all you want is an extra field in "struct ifnet" to hang driver information on, then by all means add that field. As long as you give it type "void *" and make it private to the driver I have no problem with that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.