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

[Joerg Sonnenberger]

On Sat, May 28, 2005 at 05:22:55PM -0700, Matthew Dillon wrote:
>     VLAN support?  Your ifconfig should *FAIL* if the interface can't 
>     support it in its current state.  You still only need two flags, one
>     in if_flags and one in if_capabilities.  You certainly do *NOT* need
>     three flags!

So you want to explain users why there shiny new card with hardware
VLAN tagging doesn't allow adding of VLAN? You want drivers to have to
duplicate the detection code or cleanup after the generic ethernet layer?
Also keep in mind that we have software VLAN support, which is
just slower. Just like we can do the hardware checksumming in software.

>     Same with hardware checksum support.  We only need two flags, one 
>     indicating that its possible, one indicating that it has been turned
>     on.    We don't need a flag saying it MIGHT be possible, another saying
>     that it IS posible in the current configuration, and a third saying 
>     that it's actually turned on.

I never that said. Read again what I said. Hardware support
for checksumming is one flag. The second is whether it should be used.
The third is whether is actually used. The user only plays with the
second fields. This is easy to understand and easy to implement.

Most users don't care for the specs and glitches of a card, if you want
"fail for unsupported configs with the active capabilities" mode,
you end up with a lot of confused users.  The only thing you gained
by removing the separation between iff_flags, if_capabilies and
if_capenable is the possiblity for the system to fall back to software
implementations if necessary to fullfil the user requests and switch
back when it is no longer necessary. That's a bad deal for an almost
non-existing cleanup.

Joerg