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 ...

[Joerg Sonnenberger]

On Sat, May 28, 2005 at 09:03:51AM -0700, Matthew Dillon wrote:
>     You want us to impose a trinary state on people trying to use
>     this API ?  I sure don't!

Hm? The user gets the information whether e.g. POLLING is supported
or not. Based on that, he decides whether he wants the feature or not.
Now the system can decide whether it can follow the advise of the
user or not. This is not always identical and can change.

One example is VLAN support. Let's think about a device without
native VLAN support. We can do VLAN on top of that only for MTU
=< 1492 (?). Now let's take in hardware VLAN support. The feature
exists but is not active when the MTU is > 1492. Here the desire
of the admin (hardware VLAN tagging) and the support of the card
differs. When we just disable the capability, how do we want to
activate it when the admin decides to set a smaller MTU?

Other example, hardware checksumming. A chipset supports it only for 
MTU < 8192, not above. Again, when we simply delete the capability
bit, it's gone.

Now back to polling. As far as the user is concerned, there are
two flags: IFCAP_POLLING in if_capabilities which marks those
devices which do support it and IFCAP_POLLING in if_capenable
for which the user wants polling support. IFF_POLLING is just
a hint to the user that the device is actually polled, just like
e.g. IFF_OACTIVE tells him that packets are still in the queue.
If he's not interested in the internals, he can simply ignore that
and just look at the options list.

For the system, it's also easier since IFF_POLLING can be handled
internally by the polling code changed only via ether_poll_update
(as in the patch) or via ether_poll_register / ether_poll_unregister.
I'd like to hide the latter API because they depend on the exported
knowledge when polling is actually active. Having a clear separation
between IFF_POLLING and IFCAP_POLLING is important too, because it
helps avoiding race conditions between calling the ioctl and actively
changing the internal state. That's important especially for SMP.

Joerg