public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver removals
Date: Fri, 15 Feb 2008 14:07:41 -0500	[thread overview]
Message-ID: <47B5E2FD.9060908@tmr.com> (raw)
In-Reply-To: <20080214082547.GJ12383@cs181133002.pp.htv.fi>

Adrian Bunk wrote:
> On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote:
>> ...
>> In general, if a driver works and is being used, until it *needs*  
>> attention I see no reason to replace it. I don't agree that "it forces  
>> people to try the new driver" is a valid reason, being unmaintained is  
>> only a problem if it needs maintenance. I am not going to reopen that  
>> topic, I'm simply noting a general opposition to unfunded mandates, and  
>> requiring changes to kernel, module and/or rc.local config is just that.
> 
> Keeping a working unmaintained driver in the tree is not a big deal - we 
> have hundreds of them.
> 
> But you miss the main point that removal of an obsolete driver with a 
> new replacement driver forces people to finally report their problems 
> with the new driver, thus making the new driver better.
> 
You sure are proud of that new driver! People won't use it because the 
old one is working fine, so you think it's fine to force them to make 
changes in their system to use the new driver. Best case is it works 
after costing the user some time, worst case it doesn't and breaks their 
system, so they stop upgrading the kernel and don't get security fixes.

> After all, the people who scream loudly that the new driver doesn't work 
> for them when the old driver gets removed are the people who should have 
> reported their problems with the new driver many years ago...
> 
Is it not obvious that the problem lies with the "when the old driver 
gets removed" part, there is absolutely no effort needed to keep an old 
driver, and if it's left in until some change requires rewriting every 
module in the kernel, it's likely that either the old hardware or the 
user will die before that ever happens again.

There is no benefit to users, if the old driver didn't work they would 
have switched, there's no saving in support effort because, as you 
pointed out, there are "hundreds of them" now.

This reminds me of Microsoft and XP vs. VISTA. MSFT is stopping sales 
and support of XP to "force people to upgrade" to VISTA. You want to 
"force people to upgrade" to newer drivers. The difference is that MSFT 
at least has money as a reason, as far as I can tell the reason you want 
to force people to use new drivers is because people put all the effort 
into writing the new drivers and now most of us want to use the old one 
if it works. We don't want to change configuration and hope something 
else new works, because we know the old driver works for us and we want 
to use our system instead of helping test the new driver.

I appreciate the effort it took to write new drivers, I believe most 
users able to build their own kernels do. I use new drivers on new 
systems because install picks them and a new system has to go through 
shakedown in any case. I just wish that *you* could appreciate that a 
driver change requires user effort and chance to find bugs in a new 
driver, for each and every system, many of which are at EOL now. I wish 
you valued the user's time as much as users value developer time.

*EOL - end-of-life, if your organization doesn't use the term. the "it's 
paid for, use it but don't spend money on it" phase of ownership.


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

  reply	other threads:[~2008-02-15 19:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-14  2:26 Driver removals Bill Davidsen
2008-02-14  8:25 ` Adrian Bunk
2008-02-15 19:07   ` Bill Davidsen [this message]
2008-02-15 22:28     ` Adrian Bunk
2008-02-16  1:08       ` Bill Davidsen
2008-02-16  1:52         ` Valdis.Kletnieks
2008-02-16  7:39           ` Willy Tarreau
2008-02-17  4:27             ` Valdis.Kletnieks
2008-02-16 18:11           ` Bill Davidsen
2008-02-16  7:19         ` Adrian Bunk
2008-02-16 10:52           ` David Newall

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=47B5E2FD.9060908@tmr.com \
    --to=davidsen@tmr.com \
    --cc=bunk@kernel.org \
    --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