From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 11:29:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BEF616A4B3; Tue, 30 Sep 2003 11:29:08 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B9F43FF9; Tue, 30 Sep 2003 11:29:06 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UIT2DH006492; Tue, 30 Sep 2003 11:29:03 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UIT26w006491; Tue, 30 Sep 2003 11:29:02 -0700 Date: Tue, 30 Sep 2003 11:29:02 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20030930182902.GE31908@Odin.AC.HMC.Edu> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MIdTMoZhcV1D07fI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: net@FreeBSD.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 18:29:08 -0000 --MIdTMoZhcV1D07fI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 02:23:02PM -0400, John Baldwin wrote: >=20 > On 30-Sep-2003 Brooks Davis wrote: > > On Tue, Sep 30, 2003 at 01:14:39PM -0400, John Baldwin wrote: > >>=20 > >> Fair enough. I think that Brooks planned to use a NULL device_t for > >> interfaces w/o a backing new-bus device. However, that means you > >> still need if_name for all the non-newbus devices, so this seems > >> somewhat pointless if if_name is the only reason. Another counterpoint > >> is that the new-bus namespace and the netif namespace aren't the same > >> anyway and that seemed to be the point of this linkage. The > >> dev_t <> softc <> device_t linkages aren't about unifying namespaces. > >=20 > > The idea here is that virtually all uses of if_name/if_unit that aren't > > just there for the users benefit are actually references to the > > underlying driver not name of the interface. Currently they are the > > same (i.e. ifname is nearly always device_get_name(dev) or a bug prone > > manual version there of), but I would like to separate them so we can > > rename interfaces. > >=20 > > Since device_t is as close to a repository of driver/instance > > information as we've got, I though using it would be a reasonable way > > to go. As a side benefit, most drivers have a copy of it in their softc > > already so you'd have a standard place to put it. > >=20 > > I suppose a usable alternative would be to revive if_name and if_unit > > as something like if_drvname and if_drvunit. >=20 > Are these uses all within the driver itself? If so, then just giving > ifnet a void * that is private to the driver would allow ifnet devices > hung off of new-bus devices to cache their device_t w/o requiring the > rest of the kernel to know what that private variable is. All are within other code. One example is in dev/mii/brgphy.c which a phy feature is not enabled when it is attached to some MACs. A messier example is in the new ATM code where interfaces are looked up by name. In all cases, usage is limited to a narrow set of code, but it's not generally in the driver itself (in those cases, the softc is often already used, say to hold the unit). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --MIdTMoZhcV1D07fI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ecttXY6L6fI4GtQRAjiVAJsFh1JBTe0MwR1XSCM5Jw+01j1lpgCghipY 9jOMGlXMubzG5yARuH2mFsw= =KO8S -----END PGP SIGNATURE----- --MIdTMoZhcV1D07fI--