Re: adding if_dev member to struct ifnet

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 09/30/03

  • Next message: Brooks Davis: "Re: adding if_dev member to struct ifnet" 
    Date: Tue, 30 Sep 2003 11:23:59 -0700
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    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:
    >
    > >> 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 message: Brooks Davis: "Re: adding if_dev member to struct ifnet"

    Relevant Pages

    • HEADSUP: internal network interface changes
      ... I plan to commit a major rework of network interface related storage ... driver in the system. ... the change removes the embedded struct ifnet and layer 2 common ... .Fn if_attach "struct ifnet *ifp" ...
      (freebsd-current)
    • HEADSUP: internal network interface changes
      ... I plan to commit a major rework of network interface related storage ... driver in the system. ... the change removes the embedded struct ifnet and layer 2 common ... .Fn if_attach "struct ifnet *ifp" ...
      (freebsd-net)
    • Re: HEADSUP: internal network interface changes
      ... >> softcs and replaces them with a struct ifnet pointer which is allocated ... >> longer part of the network interface ABI. ... >> action on the part of the driver without breaking the ABI. ... >> fixed before commit. ...
      (freebsd-current)
    • Re: HEADSUP: internal network interface changes
      ... >> softcs and replaces them with a struct ifnet pointer which is allocated ... >> longer part of the network interface ABI. ... >> action on the part of the driver without breaking the ABI. ... >> fixed before commit. ...
      (freebsd-net)
    • Re: adding if_dev member to struct ifnet
      ... driver routines which take a struct ifnet would know that ... driver name. ... is break the driver+unit mapping for certain types of pseudo devices. ... Specifically vlan devices should be allocatable by creating an interface ...
      (freebsd-net)