On Tue, Sep 30, 2003 at 07:56:41PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Brooks Davis writes: > > >> 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. > > 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 -- 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
pgp00000.pgp
Description: PGP signature
