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

:On Wed, May 25, 2005 at 01:13:58AM -0700, Matthew Dillon wrote:
:>    Polling is an interface capability in FreeBSD, and it works totally
:>    differently from any other standard network interface operation.  It
:>    requires reading multiple manual pages and getting help from the lists
:>    to even make it work as expected, something I'd like to avoid in 
:>    DragonFly.  It is totally non-intuitive.  The design is aweful.
:
:Beside the documenation issue, have a look at
:http://leaf.dragonflybsd.org/~joerg/polling.diff
:I want to have explicit control in the drivers, since we can use
:it as alternative to having an interrupt and disabling the cap would
:be pretty bad (stupid) in that case. Actually I'll take another round
:over the nics to factor out some more common stuff from _ioctl.
:
:Joerg

    The patch creates unnecessarily complication inside each and every
    network driver.  I would prefer to *simplify* the drivers, not make
    them more complex.

    If you really want to have an interface capability, then we could
    change the 'ifp->if_poll = blah_poll' line to a registration API
    into ether_poll.  e.g.  ether_poll_install(ifp, blah_poll), which
    could then set both the vector and the appropriate capability bit.

    However, the ifconfig changes stay.  I did change 'poll' to 'polling',
    but I've left it an IF flag rather then a capability because, frankly,
    using the capabilities bits to control an active operation is just plain
    a bad idea.  The IFF flags should be used to control an active operation,
    not the capability bits.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>