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 at apollo.backplane.com
Wed May 25 08:26:11 PDT 2005
: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 at xxxxxxxxxxxxx>
More information about the Commits
mailing list