adding if_dev member to struct ifnet

Brooks Davis brooks at one-eyed-alien.net
Tue Sep 30 10:53:04 PDT 2003


On Tue, Sep 30, 2003 at 09:10:54AM +0200, Poul-Henning Kamp wrote:
> In message <200309301045.15776.vjardin at wanadoo.fr>, Vincent Jardin writes:
> >Le Mardi 30 Septembre 2003 03:03, Brooks Davis a écrit :
> >> [Previously posted to -net in another form.]
> >>
> >> I propose to add an if_dev member to struct ifnet.  It would be of type
> >> device_t and be defined to point to the device for the interface or NULL
> >> if there is no device (or if there was not an easy way to get access to
> >> one).
> >>
> >> This change would codify the the relationship between an interface and
> >> the underlying physical device.  It also would get rid of the existing
> >> abuses of if_name to look up the driver associated with an interface
> >> and simplify a number of messy cases in the conversion from if_unit and
> >> if_name to if_xname.
> >>
> >> Does this seem like a reasonable thing to do?
> >
> >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 ?

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.

-- 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/351892a7/attachment.bin


More information about the freebsd-arch mailing list