From: Bill Davidsen <davidsen@tmr.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Kyle Rose <krose@akamai.com>, linux-kernel@vger.kernel.org
Subject: Re: sk98lin for 2.6.23-rc1
Date: Thu, 26 Jul 2007 19:38:34 -0400 [thread overview]
Message-ID: <46A9307A.5000502@tmr.com> (raw)
In-Reply-To: <20070726165701.GM3572@stusta.de>
Adrian Bunk wrote:
> On Thu, Jul 26, 2007 at 11:16:36AM -0400, Kyle Rose wrote:
>> >From http://www.krose.org/~krose/computing.html:
>>
>> Since the sky2 driver continues to suck ass (which is a technical
>> description for "it hangs all the time under load, at least on my
>> hardware" :-) ), I've fixed the sk98lin driver to compile for
>> linux-2.6.23-rc1. Those who continue to have problems with sky2 can
>> still use 2.6.23-rc1, simply by doing the following:
>> ...
>> Personally, I'd like to see sk98lin remain in the kernel proper until
>> sky2 goes at least 6 months without reported problems. The fact that I
>> am not the only one still seeing issues is a clear indication that sky2
>> (even with the recent patches in 2.6.23-rc1) is not yet ready to replace
>> sk98lin.
>> ...
>
> This sounds good in theory.
>
> The practical problem with this approach is that there are always many
> people who use the old driver when the new driver doesn't work for them
> instead of reporting their problems with the new driver.
>
Yes, you've grasped the reason for leaving the old driver in, so people
can use their computers. Because when there is a new driver for
previously unsupported hardware people will be glad to put time into
debugging it to make the hardware useful. But when you take out a
working driver because you (ie. the responsible developer) have a new
idea which interests you, users don't want to use it because they have
something which works, so you take out the working driver to make work
for the users and create what you call a "better new driver" below.
The old driver wasn't requiring any resources to maintain, the old
hardware wasn't changing, there was no particular benefit to users in
breaking their configuration. This disregard for the users just gives
Linux critics an arguing point, "the next new kernel may withdraw
support for your hardware." Isn't that why 2.6.16 is still being
maintained? Nobody (sane) expects new drivers to be perfect, they just
don't expect the working drivers to be disabled.
> For these people a new driver will often suck when the old driver gets
> removed, but after the removal of the old driver they are finally forced
> to report their bugs resulting in a better new driver for everyone.
>
"Better" is a very subjective thing, you see elegance of design perhaps,
I see works or not, and when I have to use statistical methods to see
latency or CPU overhead benefits, I frankly don't care.
Removing a working driver without a fully functional replacement forces
people to stop upgrading their kernel, or start maintaining old drivers
out of line. Problems of the "just occasionally goes away" type can take
months to debug, the load can't be duplicated in most cases, and there's
no log or oops data to help.
> The sky2 driver is since nearly 2 years in the kernel and Stephen is
> usually quite good at handling bugs.
>
Where does sky2 come in? Does this mean the the recent suggestion to
"just change to skge and stop complaining" is also wrong?
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
next prev parent reply other threads:[~2007-07-26 23:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 15:16 sk98lin for 2.6.23-rc1 Kyle Rose
2007-07-26 16:28 ` Jan Engelhardt
2007-07-26 16:30 ` Kyle Rose
2007-07-26 16:41 ` Jan Engelhardt
2007-07-27 1:07 ` Kyle Rose
2007-07-26 16:57 ` Adrian Bunk
2007-07-26 22:58 ` Chris Stromsoe
2007-07-26 23:38 ` Bill Davidsen [this message]
2007-07-26 23:41 ` Jeff Garzik
2007-07-30 3:01 ` Rob Sims
2007-09-05 9:22 ` Stephen Hemminger
2007-09-05 19:42 ` James Corey
2007-09-05 21:04 ` Kyle Rose
2007-09-05 23:00 ` Stephen Hemminger
2007-09-08 17:44 ` Bill Davidsen
2007-09-08 19:11 ` Adrian Bunk
2007-09-09 2:42 ` Kyle Rose
2007-09-09 4:48 ` Willy Tarreau
2007-09-09 11:13 ` Adrian Bunk
2007-09-11 8:05 ` Stephen Hemminger
2007-09-11 11:54 ` Adrian Bunk
2007-09-11 14:29 ` Bill Davidsen
2007-09-11 15:03 ` Adrian Bunk
2007-09-11 22:37 ` Willy Tarreau
2007-09-11 22:20 ` James Corey
2007-09-09 12:54 ` Chris Stromsoe
2007-11-06 22:23 ` Stephen Hemminger
2007-11-07 1:42 ` Chris Stromsoe
2007-09-10 14:32 ` Bill Davidsen
2007-09-10 15:39 ` Adrian Bunk
2007-09-11 4:23 ` Kyle Moffett
2007-09-12 16:46 ` Torsten Kaiser
2007-07-26 19:17 ` Stephen Hemminger
2007-07-26 23:52 ` Bill Davidsen
2007-07-27 1:13 ` Kyle Rose
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=46A9307A.5000502@tmr.com \
--to=davidsen@tmr.com \
--cc=bunk@stusta.de \
--cc=krose@akamai.com \
--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