linux-kernel - Re: sk98lin for 2.6.23-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46E5558D.3030402@tmr.com>
Date:	Mon, 10 Sep 2007 10:32:45 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Adrian Bunk <bunk@...nel.org>
CC:	James Corey <ploversegg@...oo.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Rob Sims <lkml-z@...sims.com>, Kyle Rose <krose@...mai.com>,
	linux-kernel@...r.kernel.org
Subject: Re: sk98lin for 2.6.23-rc1

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! skge 
crashes the system, as Chris reports, sky2 just stops passing bits and 
behaves as if the network cable were idle, no error messages of any 
nature, ping claims it's sending packets, tcpdump claims packets are 
being sent, the switch never blinks and systems on the switch see no 
packets. Again, no error messages, no dumps, nothing which would help 
you debug it, and it happens after some undefined time.

skge and sky2 are up to eight or ten versions now, and they still don't 
work. Just because a driver works doesn't mean it's 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.

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.

-- 
bill davidsen <davidsen@....com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/