linux-kernel - Re: Driver removals

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]

Date:	Sat, 16 Feb 2008 08:39:08 +0100
From:	Willy Tarreau <w@....eu>
To:	Valdis.Kletnieks@...edu
Cc:	Bill Davidsen <davidsen@....com>, Adrian Bunk <bunk@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Driver removals

On Fri, Feb 15, 2008 at 08:52:27PM -0500, Valdis.Kletnieks@...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

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