David S. Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Wed, 24 Apr 2002 10:31:29 -0700
>
> Maybe it could just WARN and still bring it up, if it's just
> an MTU issue? (Or is this a total failure of VLAN support you
> are talking about?)
>
> This creates a support issue. It's almost impossible to field
> bug reports effectively once you start letting users do stuff
> like this.
We let users do much worse: rm -fr /
won't even warn you. I'm all for warning the user, but since the
MTU issue can be worked around by setting the VLAN MTU to 1496,
and sometimes setting the eth0 MTU to 1504, then putting hard
restrictions in the kernel sounds like a really bad idea.
> Also, is there any good reason that we can't get at least a compile
> time change into some of the drivers like tulip where we know we can
> get at least MOST of the cards supported with a small change?
>
> I know the driver writers hate cruft in the drivers, but we have had
> ppl using the patches in production machines for months, if not years,
> with no ill effects.
>
> But the changes are wrong, just because they work for some people
> doesn't make the change mergeable into the main tree.
Wrong is a strong word for a change that makes it work for some people without
obvious negative side effects. I can understand not putting the changes in
by default, but a module-load flag, or a compile time check is much easier
to support than telling the user to go patch their driver and come back when
they figure out how to do that... It will also allow users to easily test
the patches on all their various systems.
> The same argument applies to the EEPRO driver (we know a cure, but it's
> a magic register number, and no one will accept the patch).
>
> Intel is making strides with their e1000 and e100 drivers, just give
> them some time.
That is good news, but does not change my arguments about fixing up
the eepro driver at all :)
> Also Jeff is in a rut right and busy with some things, once he gets
> back up to speed you can expect a lot of these issues to be dealt
> with.
I'm looking forward to Jeff's return. I still haven't heard if he
ever figured out why 3 DFE-570-tx (4-port) tulip nics cannot exist
in the same system :)
Ben
>
> Franks a lot,
> David S. Miller
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 30 2002 - 22:00:09 EST