Date: Tue, 24 Jan 2006 11:30:50 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Sam Leffler <sam@errno.com> Cc: current@freebsd.org Subject: Re: if_flags usage etc. Message-ID: <20060124113050.A76608@xorpc.icir.org> In-Reply-To: <43D67C6E.7020403@errno.com>; from sam@errno.com on Tue, Jan 24, 2006 at 11:13:50AM -0800 References: <20060124075437.B67285@xorpc.icir.org> <43D67C6E.7020403@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 be reorganized. I don't think there is an issue with binary-only drivers but there is certainly one in sharing code with the other BSD's... > 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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060124113050.A76608>