DragonFly BSD
DragonFly commits List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Wed, 25 May 2005 17:41:31 +0200
Mail-followup-to: commits@crater.dragonflybsd.org

On Wed, May 25, 2005 at 08:24:25AM -0700, Matthew Dillon wrote:
>     The patch creates unnecessarily complication inside each and every
>     network driver.  I would prefer to *simplify* the drivers, not make
>     them more complex.

We could conditionalize the IFCAP processing based on the return value
of if_ioctl, other ways are possible too. There's a lot to do and for
most drivers it can be done without problems in ether_ioctl (those who
don't have other changeable capabilities).

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

It is as active as e.g. hardware checksumming. It is necessary to differ
because an user can't tell which interface supports polling otherwise.
It doesn't even change the modus operandi if we ignore latency and
interrupt overhead for a moment, read: the NIC continues to work the
same from the point of higher levels. That's completely different from the
other IFF flags.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]