From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 11:24:03 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 49BCE16A4BF; Tue, 30 Sep 2003 11:24:03 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7589D43FB1; Tue, 30 Sep 2003 11:24:02 -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 h8UIO0DH005560; Tue, 30 Sep 2003 11:24:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UINxci005559; Tue, 30 Sep 2003 11:23:59 -0700 Date: Tue, 30 Sep 2003 11:23:59 -0700 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20030930182359.GD31908@Odin.AC.HMC.Edu> References: <20030930171535.GA31908@Odin.AC.HMC.Edu> <13247.1064944601@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d9ADC0YsG2v16Js0" Content-Disposition: inline In-Reply-To: <13247.1064944601@critter.freebsd.dk> 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: 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 18:24:03 -0000 --d9ADC0YsG2v16Js0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 07:56:41PM +0200, Poul-Henning Kamp wrote: > In message <20030930171535.GA31908@Odin.AC.HMC.Edu>, Brooks Davis writes: >=20 > >> Somebody please explain how this would work for non-hardware > >> interfaces like if_loop, if_tun, if_tap etc ? > > > >if_dev would be NULL when a device_t was not available. Code which used > >this feature would be required to either check that if_dev was non-NULL > >before trying to use it or have special knowldege that it only gets > >called with struct ifnet instances which have a non-NULL if_dev member. > >For instance, driver routines which take a struct ifnet would know that > >they are only called on their own ifnet so they could assume they had > >filled it in. >=20 > So you'd still have to keep the if_name + if_unit around for the > drivers which do not have a device_t ? Not today, since none of them get used in the paths that do this. In general the network code doesn't care what you call an interface. There are a few corners where it does, but nothing that isn't specific to a certain set of drivers. Additionally, it is necessary to not have members called if_name and if_unit if we have if_xname as the primary driver name. It's also worth noting that one of the things I want to do is break the driver+unit mapping for certain types of pseudo devices. Specifically vlan devices should be allocatable by creating an interface with a name like fxp0.100 so while you could synthesize a unit number, it wouldn't have any useful meaning. -- 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 --d9ADC0YsG2v16Js0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eco2XY6L6fI4GtQRAuwDAKCe31Th8L2pVT14zAG+ZhB6LcnLtgCfZwWC S7NMTkdh6BZHwpbsmj/FSL8= =7Rec -----END PGP SIGNATURE----- --d9ADC0YsG2v16Js0--