cvs commit: src/sys/i386/i386 nexus.c src/sys/i386/include atomic.h src/sys/kern kern_poll.c lwkt_serialize.c src/sys/net if.c if_var.h rtsock.c src/sbin/ifconfig ifconfig.c src/sys/dev/netif/dc if_dc.c src/sys/dev/netif/em if_em.c if_em.h ...
dillon at apollo.backplane.com
Thu May 26 14:09:15 PDT 2005
:On Thu, May 26, 2005 at 01:36:41PM -0700, Matthew Dillon wrote:
:> This doesn't solve any of the problems I brought up. First, turning on
:> and off polling should NOT be done with the capabilities bitmask. I don't
:> know why you keep trying to revert the ifconfig change. Operational
:> flags are if_flags, *NOT* if_capabilities.
:Exactly that is the point. IFF_POLLING is the operational flag, it means
:"this interface uses polling". That is completely different from "this
:interface supports polling" and "this interface should use polling".
:We would have to add yet another interface to indicate the first.
:> The capabilities bitmask is
:> a list of capabilities, *period*. It is NOT what controls whether
:> a capability is turned on or off.
:There are *two* capability bitmasks. The first describes which
:capabilities are supported (if_capabilities), that's what you removed
:in the first patch set. The second is if_capenable, which describes
:the desired interface state. It contains the *administrative* state,
:which is modified by ifconfig. if_capabilities is *never* modified
Which is garbage we inherited from FreeBSD. We should use if_flags
for the desired interface state and if_capabilities should simply be a
reflecting of which IF flags are supported, instead of having a
separate IFCAP flag set.
:Well, whether we want to hide this with a yet another function
:is a completely different issue. I don't have a problem with that,
:but it doesn't save that much.
It causes the code to either be properly implemented, or not implemented
at all, instead of half-implemented (like most of the drivers do now).
This is an important coding abstraction.
<dillon at xxxxxxxxxxxxx>
More information about the Commits