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

:This is OK.
:
:>   simply allow IFF_POLLING to be set and cleared via ifconfig.  This greatly
:
:This is *not* OK.
:
:>   The kernel polling code no longer randomly turns off the polling bit if an
:>   interface goes down or is reset.
:
:It's the same as why we distinguish between IFF_RUNNING and IFF_UP.
:The first is the internal state, the latter is an administrative decision.
:There is no need to run the polling header for inactive interactive, but
:even more important, there is no need to have them in the queue, since
:the code has to loop through all the polling handlers.
:
:>   Remove IFCAP_POLLING, it serves no purpose.
:
:It's the mechanism used to activate polling. Polling is an interface
:capability, removing it at the very least removes the information if
:polling is supported.
:
:Joerg

   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.

   Since we aren't FreeBSD we can do it right... that is to say, we can make
   it a standard ifconfig flag that can be trivially turned on and off
   at a whim rather then a hack.  And that is what I have done.  Polling
   is no different from an interface that might or might not support, say,
   a broadcast address, or multicast, or other features.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>