if_flags usage etc.
rizzo at icir.org
Tue Jan 24 11:31:01 PST 2006
On Tue, Jan 24, 2006 at 11:13:50AM -0800, Sam Leffler wrote:
> Luigi Rizzo wrote:
> > - very few places outside drivers look at IFF_DRV_RUNNING. Basically.
> > net/if_ethersubr.c, netinet/ip_fastfwd.c , net80211/ieee80211_ioctl.c
> > in all cases checking that both IFF_UP and IFF_RUNNING are set.
> > I am not sure why we need both.
> IFF_UP is set by administrative choice and is different from IFF_RUNNING
> which means the device/driver is operational. We'd need to look at the
> cases where both are checked; it's likely the decision making is
> muddled. I know when I did the virtual ap stuff that the distinction
> between the two became very important so I believe it is good to keep both.
ok, i have no intention to kill either of them, am just unsure on
the usage patterns, especially because IFF_RUNNING is set/cleared
by the driver and the network layer looks at it without any locking, so
it may well see stale information, at which point i wonder why
look at IFF_RUNNING at all, and not just rely on IFF_UP
being reset one way or another upon errors.
It happens already (e.g. i see my "iwi" card clearing IFF_UP
when the association is lost), i just haven't figured out how.
> This list looks very incomplete; I'm aware of many drivers that alter
i know, i am trying to build a more complete list compiling modules.
> IFF_UP incorrectly. One reason drivers touch IFF_UP is because if_init
> has no return value so drivers use IFF_UP to indicate whether or not the
> device initialization was successful. I held off changing the type
> signature for this method but think it's time to change it in HEAD.
which raises the issue - what constraints do we have on changing
things here ? E.g. the splitting of flags, and more in
general the struct ifnet, which has lot of stuff that should
I don't think there is an issue with binary-only drivers
but there is certainly one in sharing code with the other
> Another area where there is major confusion is in handling ioctls that
> change driver/device state. The basic model appears to be that an upper
> layer changes state then calls the device if_init method to push state
> into the hardware. However this puts the onus on the driver to identify
> what has changed if it wants to optimize this work; otherwise it has to
right... in fact the 'optimized' drivers keep a shadow copy of the
interesting flags (in many case IFF_PROMISC) and the non-optimized
ones just reinit the device on all changes.
More information about the freebsd-current