lkml.org 
[lkml]   [2007]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sk98lin for 2.6.23-rc1
On Mon, Sep 10, 2007 at 10:32:45AM -0400, Bill Davidsen wrote:
> Adrian Bunk wrote:
>> On Sat, Sep 08, 2007 at 01:44:20PM -0400, Bill Davidsen wrote:
>>
>>> ...
>>> That was with 2.6.22.5 (or so), dropped back to an old kernel with
>>> sk98lin, previously had uptimes in three digit days. Up for a week or so
>>> now.
>>>
>>
>> There is a real long-term advantage of removing drivers like sk98lin
>> because it forces people to report bugs if the new driver doesn't work
>> instead of giving them the workaround of using the obsolete driver.
>
> The issue is that sk98lin is only obsolete because you say so!

No, it is obsolete because we have more than one driver for this
hardware, and the people responsible for network drivers in the kernel
decided some time ago that sk98lin is the one that is obsolete.

>...
>> And this has the (at first sight surprising) effect that removing code
>> results in an improvement of the kernel.
>>
>>
>>> Haven't tried later kernels, don't intend to, while no network is really
>>> secure, it not really useful.
>>>
>>
>> You are a regular reader of linux-kernel, and therefore the sk98lin
>> removal can hardly be a surprise for you. If you prefer whining over
>> helping to improve the kernel that's your choice...
>>
>
> I am trying to "improve the kernel" by advocating not removing reliable
> drivers in favor of unreliable drivers. Saying a driver is better because
> it has a clean design and good code is something I would expect from
> someone who hadn't written or used code. If skge and sky2 were so clean you
> wouldn't still be chasing obscure bugs after the driver had been in the
> kernel for six+ versions, you wouldn't have me wasting time trying to get a
> more secure kernel which is still reliable, wouldn't have Willy Tarreau
> suggesting you should be marking sk98lin as obsolete and leaving it in,
> wouldn't have someone maintaining sk98lin as a patch, wouldn't have Chris
> Stromsoe getting hard lock-ups. No matter how ugly sk98lin looks, and how
> well designed skge and sky2 may be, reliability is not a beauty contest.

A better written driver might still lack some workarounds for broken
hardware or similar problems. Or simply contain some bugs like all
software does.

The important word is not "reliability", it's "maintainability".
And that's something that pays off in the long term.

> The volume of complaint should give you a hint that in this case the new
> drivers aren't usefully stable for many people, and that you are advocating
> a removal which is at least premature. If you can't admit you're wrong on
> this one, you can say you have reconsidered the timing of removal in light
> of new information.

It was clear that sk98lin would go in the long term, and the only thing
that could be discussed is the when and how of removal.

When you talk about "new information", why did this information not
surface until after the sk98lin driver was removed?

Is there really a problem with "the timing of removal" or would we have
faced exactly the same problems if the removal was timed a year later?

And this is really the essence when I'm saying "removing code improves
the kernel": The goal is to get people to report if the new drivers
aren't usefully stable for them, not to use sk98lin instead without
sending a bug report.

Having different drivers with different sets of bugs and features is
not a situation that should be retained for a longer time.

The underlying question is:
Is there anything better than a quick removal of the obsolete driver to
get people to both test and report bugs with the new driver?
Keeping obsolete drivers longer only for running into exactly the same
problem later isn't an improvement.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

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

\
 
 \ /
  Last update: 2007-09-10 17:43    [W:0.138 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site