From: Ben Greear <greearb@candelatech.com>
To: "David S. Miller" <davem@redhat.com>
Cc: jd@epcnet.de, linux-kernel@vger.kernel.org
Subject: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x
Date: Wed, 24 Apr 2002 10:58:06 -0700 [thread overview]
Message-ID: <3CC6F22E.9060402@candelatech.com> (raw)
In-Reply-To: <721506265.avixxmail@nexxnet.epcnet.de> <20020424.095951.43413800.davem@redhat.com> <3CC6EBF1.9060902@candelatech.com> <20020424.102528.98393867.davem@redhat.com>
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
next prev parent reply other threads:[~2002-04-24 17:58 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-24 15:09 VLAN and Network Drivers 2.4.x jd
2002-04-24 13:04 ` David S. Miller
2002-04-24 16:23 ` AW: " jd
2002-04-24 16:35 ` David S. Miller
2002-04-24 17:03 ` AW: " jd
2002-04-24 16:59 ` David S. Miller
2002-04-24 17:31 ` Ben Greear
2002-04-24 17:25 ` David S. Miller
2002-04-24 17:58 ` Ben Greear [this message]
2002-04-24 17:56 ` David S. Miller
2002-04-24 19:43 ` Ben Greear
2002-04-24 22:23 ` AW: " jd
2002-04-24 17:49 ` Jeff Garzik
2002-04-24 18:04 ` Ben Greear
2002-04-24 18:10 ` Jeff Garzik
2002-04-24 18:07 ` Matti Aarnio
2002-04-24 18:13 ` Jeff Garzik
2002-04-24 17:42 ` AW: " jd
2002-04-24 17:40 ` David S. Miller
2002-04-24 22:28 ` AW: " jd
2002-04-24 22:21 ` David S. Miller
2002-04-25 4:26 ` AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: [was: VLAN and Network Drivers 2.4.x] Dax Kelson
[not found] ` <200204242141.02957.bodnar42@phalynx.dhs.org>
2002-04-25 4:43 ` Ryan Cumming
2002-04-25 10:19 ` Matthias Andree
2002-04-25 13:45 ` AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x jd
2002-04-26 0:46 ` David S. Miller
2002-04-27 20:34 ` jd
2002-04-28 2:43 ` David S. Miller
2002-04-28 20:28 ` jd
2002-04-29 3:49 ` David S. Miller
2002-04-29 5:20 ` How to enable printk Wanghong Yuan
2002-04-28 6:33 ` Uilton Dutra
2002-04-29 6:33 ` Itai Nahshon
2002-04-29 6:52 ` Chris Wright
2002-04-29 11:37 ` David Woodhouse
2002-04-30 17:12 ` Denis Vlasenko
2002-04-30 12:55 ` David Woodhouse
2002-04-30 18:03 ` Denis Vlasenko
2002-04-30 13:14 ` David Woodhouse
2002-04-29 22:15 ` Accurately measure CPU cycles used by a program? thanks Wanghong Yuan
2002-04-29 22:22 ` J.A. Magallon
2002-04-30 16:30 ` Zach Brown
2002-05-10 23:49 ` Corey Minyard
2002-04-30 22:15 ` what replaces tq_scheduler in 2.4 Wanghong Yuan
2002-04-30 22:31 ` Andrew Morton
2002-05-02 15:44 ` Ingo Oeser
2002-05-03 0:13 ` Wanghong Yuan
2002-05-03 18:04 ` Andrew Morton
2002-05-01 6:41 ` suspend a thread in LKM Wanghong Yuan
2002-04-29 9:06 ` VLAN and Network Drivers 2.4.x jd
2002-04-25 10:20 ` Matthias Andree
2002-04-24 16:39 ` AW: " Pasi Kärkkäinen
2002-04-24 16:18 ` Ben Greear
2002-04-24 16:46 ` AW: " jd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CC6F22E.9060402@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@redhat.com \
--cc=jd@epcnet.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox