adding if_dev member to struct ifnet
Brooks Davis
brooks at one-eyed-alien.net
Tue Sep 30 11:24:03 PDT 2003
On Tue, Sep 30, 2003 at 07:56:41PM +0200, Poul-Henning Kamp wrote:
> In message <20030930171535.GA31908 at Odin.AC.HMC.Edu>, 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20030930/3e3ebf91/attachment.bin
More information about the freebsd-arch
mailing list