netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	Kyle Rose <krose@krose.org>, James Corey <ploversegg@yahoo.com>,
	Rob Sims <lkml-z@robsims.com>,
	linux-kernel@vger.kernel.org, Jeff Garzik <jeff@garzik.org>,
	netdev@vger.kernel.org
Subject: Re: sk98lin for 2.6.23-rc1
Date: Tue, 11 Sep 2007 10:29:47 -0400	[thread overview]
Message-ID: <46E6A65B.2050209@tmr.com> (raw)
In-Reply-To: <20070911115456.GM3563@stusta.de>

Adrian Bunk wrote:
> On Tue, Sep 11, 2007 at 10:05:26AM +0200, Stephen Hemminger wrote:
>   
>> There are several different problems in this thread:
>> 1. The removal of old sk98lin driver caused some users to be forced to use
>>     skge. These users have uncovered issues with the dual port fiber based versions
>>     of the board.  
>>     Short term: The sk98lin driver should be restored to previous state, 
>>        and the PCI table should be used to limit the usage to only fiber systems.
>>        If Adrian doesn't do it, I'll do it when I return from Germany.
>> ...
>>     
>
> No problem with this, but since it was Jeff's patch it should better be 
> him who reverts it (and he's anyway one step nearer to Linus).
>
> But the underlying general problem still remains:
>
> How can we get people to test and report bugs with the new drivers 
> before removing the old driver?
>
>   
Sorry for a long answer, I'm trying to provide insight on two recent cases.

Thinking back to several drivers, when e100 was new I tried it because I 
had problems with eepro100 in the area of multiple cards, multiple 
cables on a single card, and jumbo packets. For a while I used both, 
until e100 worked where I need it. So I initially tried it because it 
had features I needed, and then dropped to older driver just to avoid 
having to decide.

With sk98lin, the driver worked flawlessly with all (3-4) systems, so I 
had no reason to try any other. When removing sk98lin was first 
proposed, I tried skge, first measurements showed it was 5-8% slower, 
NOT what I want, so I went back. For me there was no reliability issue, 
but I never tried it in a system with more than on NIC on the driver. 
Would "it's a little slower" be a valid bug report? Or would I have 
gotten "works fine for me" from people not beating it over Gbit? I 
didn't try sky2 until you suggested it, and I have reported my results 
previously, just stops working. Could it be my hardware? I tried it on 
one system, so yes, but sk98lin works for months.
> That's a question especially for the people who now had problems after 
> sk98lin was removed.

So if you want people to try a new driver, I think it really has to have 
some benefits to the users, in terms of performance, reliability, or 
features. "Cleaner design" doesn't motivate, and it does raise the 
question of why the old driver wasn't just cleaned up. I've been doing 
software for decades, I appreciate why, but users in general just want 
to use their system. Which raises the question of why to delete drivers 
which work for many or even most users? Testing a new kernel is no 
longer a drop in a boot operation if modprobe.conf must be edited to get 
the network up, and the typical user isn't going to write that shell 
script to try one or the other driver.

Honestly, new drivers which offer little benefit to most users are the 
exception rather than the rule, so this may a corner case I would like 
to see sk98lin back in the kernel, for a while I can build my own 
kernels and patch it in, but until other drivers are drop-in, I probably 
won't change.

Separate but related: why keep skge and sky2? Are we going through this 
again in a year? Is the benefit worth the effort?

Hope some of this is helpful.

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


  reply	other threads:[~2007-09-11 14:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070905102230.10b0bdcf@oldman>
     [not found] ` <782111.42803.qm@web90413.mail.mud.yahoo.com>
     [not found]   ` <46E2DF74.7040307@tmr.com>
     [not found]     ` <20070908191132.GD3563@stusta.de>
     [not found]       ` <46E35D8C.1070909@krose.org>
     [not found]         ` <20070909111326.GF3563@stusta.de>
     [not found]           ` <20070911100526.6aa5d463@oldman>
2007-09-11 11:54             ` sk98lin for 2.6.23-rc1 Adrian Bunk
2007-09-11 14:29               ` Bill Davidsen [this message]
2007-09-11 15:03                 ` Adrian Bunk
2007-09-11 22:37                   ` Willy Tarreau
2007-07-27 19:27 Daniel J Blueman
     [not found] <46A8BAD4.8020004@akamai.com>
     [not found] ` <20070726201731.03d3f590@oldman>
     [not found]   ` <46A8F3EE.3070102@krose.org>
2007-07-27  8:13     ` Stephen Hemminger
2007-07-27 12:58       ` Jeff Garzik
2007-07-27 13:06         ` Stephen Hemminger

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=46E6A65B.2050209@tmr.com \
    --to=davidsen@tmr.com \
    --cc=bunk@kernel.org \
    --cc=jeff@garzik.org \
    --cc=krose@krose.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml-z@robsims.com \
    --cc=netdev@vger.kernel.org \
    --cc=ploversegg@yahoo.com \
    --cc=shemminger@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).