From: Bill Davidsen <davidsen@tmr.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Harvey Harrison <harvey.harrison@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
Jiri Slaby <jirislaby@gmail.com>, Pavel Machek <pavel@suse.cz>,
Christoph Hellwig <hch@lst.de>,
Dominik Brodowski <linux@brodo.de>, Andi Kleen <ak@suse.de>,
Adrian Bunk <bunk@stusta.de>,
Arjan van de Ven <arjan@linux.intel.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
Nick Piggin <npiggin@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
Len Brown <len.brown@intel.com>
Subject: Re: Feature Removals for 2.6.25
Date: Thu, 14 Feb 2008 13:16:04 -0500 [thread overview]
Message-ID: <47B48564.1010709@tmr.com> (raw)
In-Reply-To: <20080213185502.0005dd4d@extreme>
Stephen Hemminger wrote:
>>> Ping?
>>> What: sk98lin network driver
>>> When: Feburary 2008
>>> Why: In kernel tree version of driver is unmaintained. Sk98lin driver
>>> replaced by the skge driver.
>>> Who: Stephen Hemminger <shemminger@linux-foundation.org>
>>>
>>> ---------------------------
>>>
>> We have been over this several times, and I thought someone had taken
>> over the driver and was providing patches to put it in. Both skge and
>> sky2 have been proposed as the replacement, people have reported
>> problems with each. Suggest leaving this alone until the sk98lin
>> actually needs work, then take it out. Problems in my problem system
>> have been intermittent, take 4-40 hours to show and generate no errors,
>> other than the driver thinks it's sending packets and the sniffer doesn't.
>>
>
> The vendor sk98lin driver will continue it's happy life out of tree.
> The version in 2.6.25 is ancient and unmaintained and only supports older
> hardware. There are no outstanding issues with skge driver (sky2 is
> prone to hardware problems, but then so is vendor driver).
>
And those of us who are using it *have* old hardware. Old hardware that
perhaps the people forcing other driver on us don't have.
> Unfortunately, removing sk98lin seems to be the only way to make die
> hard users report problems. The last time we removed it, some user's of
> old Genesis boards showed with issues, but those are now fixed.
>
I guess I have a real problem with the "make die hard users report
problems" thing, because it assumes that there is nothing wrong with
*causing* us problems. Understand, this is not "change is bad" but
"change is expensive." Because it means a change in kernel config,
modules.conf, and possibly rc.local or initrd or similar. A per-machine
effort which is small in ones, and large in sum.
> Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably
> be gone from -mm before that).
>
>
If this were a case of the sk98lin driver needing work, I wouldn't be
making the argument. But to make work for users in a case where there is
no saving in effort for developers, sounds as if the developers place no
value at all on the time of the people who build their own kernels, and
if the vendors are good with it, that's all that matters.
Note that because the hardware is old, it's highly likely that most of
it will be retired before that sk98lin driver needs a change. I can't
see anyone using sk98lin on a new system, so it would be less
contentious to let the hardware (or users) die of natural causes if you can.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2008-02-14 18:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-01 1:38 Feature Removals for 2.6.25 Harvey Harrison
2008-02-01 4:53 ` Arjan van de Ven
2008-02-01 5:18 ` Harvey Harrison
2008-02-01 6:33 ` Arjan van de Ven
2008-02-01 7:04 ` Harvey Harrison
2008-02-01 5:02 ` Feature Removals for 2.6.25 (USB driver api) Greg KH
2008-02-01 7:08 ` Feature Removals for 2.6.25 Stephen Hemminger
2008-02-02 1:29 ` Nick Piggin
2008-02-03 10:44 ` Feature Removals for 2.6.25 - old NCR53C9x driver Boaz Harrosh
2008-02-14 2:49 ` Feature Removals for 2.6.25 Bill Davidsen
2008-02-14 2:55 ` Stephen Hemminger
2008-02-14 18:16 ` Bill Davidsen [this message]
2008-02-14 18:24 ` Arjan van de Ven
2008-02-14 18:26 ` Christoph Hellwig
2008-02-14 23:20 ` David Newall
2008-02-15 3:27 ` Rene Herman
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=47B48564.1010709@tmr.com \
--to=davidsen@tmr.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bunk@stusta.de \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=harvey.harrison@gmail.com \
--cc=hch@lst.de \
--cc=jirislaby@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@brodo.de \
--cc=npiggin@suse.de \
--cc=pavel@suse.cz \
--cc=randy.dunlap@oracle.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