From: Willy Tarreau <w@1wt.eu>
To: Valdis.Kletnieks@vt.edu
Cc: Bill Davidsen <davidsen@tmr.com>, Adrian Bunk <bunk@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Driver removals
Date: Sat, 16 Feb 2008 08:39:08 +0100 [thread overview]
Message-ID: <20080216073907.GT8953@1wt.eu> (raw)
In-Reply-To: <26601.1203126747@turing-police.cc.vt.edu>
On Fri, Feb 15, 2008 at 08:52:27PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said:
>
> > can never make you see why technological extortion is evil. People have
> > always moved to new drivers without pushing because they were *better*,
> > guess that model is dead.
>
> And the drivers get better because the Code Fairy comes and sprinkles magic
> bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix
> dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust?
>
> Yes, people will move without pushing when the drivers are better. However,
> remember that a major cultural motivation for the GPL is the concept of "give
> back". And if a user can't be bothered to even give back enough to say
> "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a
> problem with the user.
I don't understand why kernel developers always think that users spend
their whole time testing their new stuff. That is mostly true for a lot
of desktop users, but definitely not for servers. On a server, you may
*ignore* that a new driver exists for years. The basic make oldconfig
does the stuff right.
An old driver must spend some time marked "deprecated", if possible with
the config option changed so that at least *something* informs the admin
that it may soon be removed. It looks like this is something that people
building a kernel every day and never getting more than one week of uptime
do not understand. But there are many people who build once a year and
upgrade that often at most, unless there is a big security issue.
If the old driver simply keeps silently building when marked deprecated,
noone will notice. And as Bill pointed it out, we should also make sure
that when marked deprecated, the old one always refers to the new one so
that the guy noticing this during the build has time to set up a test
machine to try that new driver.
Not everyone has a mouse and a joystick attached to the computers he
builds kernels for...
Willy
next prev parent reply other threads:[~2008-02-16 7:39 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
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 [this message]
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=20080216073907.GT8953@1wt.eu \
--to=w@1wt.eu \
--cc=Valdis.Kletnieks@vt.edu \
--cc=bunk@kernel.org \
--cc=davidsen@tmr.com \
--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