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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:As the guy who came up with IFCAP (yeah, shoot me now), one of the
:motivating factors was to provide the ability to report to the user
:(via the unintuitive 'ifconfig -m') what the device can actually support.
:
:This came about because people constantly were asking why their ifconfig
:command didn't 'take' when they tried turning on checksumming.  I'd
:imagine this would be the same problem for polling.  For the most part
:I'd think that simply turning on capabilities would be handled in the 
:net/if.c code ; checksums can't do this, as they calls into the driver
:in order to restart the NIC.  An ether_install(..) call for capabilities
:would be nice.
:-- 
:Jonathan

    I agree mostly.  One that includes a dispatch function when necessary. 
    So something like this (the driver code would call):

	ether_install_capability(ifp, IFCAP_POLLING, fubar_poll_function);

    Or less generically (if the argument spec varies too much):

	ether_install_polling(ifp, fubar_poll_function);

    The procedure would then do all the necessary work to install the
    capability, e.g. in this case it would assign the function pointer
    to if_poll and set the IFCAP bit.  That way there is no way the driver
    can accidently 'half-implement' the feature.

    Such a function could also check the kernel environment to see if the
    capability should be turned on by default or not.

    My main desire is to simplify the APIs.  e.g. Having the driver's
    *interrupt* routine try to register the poll really complicates the
    poll registration code.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>