Just a general thought on removing drivers in general, when a driver is

removed because there's a better one, it would be good to have either a

message which shows up at "make oldconfig" time, or a file listing the

driver(s) which replace it.
Half the resistance to removing drivers is finding what is supposed to

replace the driver. For instance a list of all the drivers Adrian Bunk

has suggested to replace sk98lin, so users have something better than

searching the source code and/or LKML archive to find the next thing to try.
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.
--

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

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

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

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

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 f...
[ message continues ]

Sometimes what is best in the global picture is not what everyone

subjectively considers to be the best thing for him.
Instead of sending a bug report?
When removing an obsolete driver adult people suddenly start whining

"the new driver didn't work for me when I tried it one year ago".
And when asking where they reported the bug in the new driver the answer

is that they didn't report it.
Driver development heavily relies on getting bug reports when something

doesn't work.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

If you don't see an ethical problem in removing a working driver which

is not taking support resources, in order to force people to test and

debug a driver they don't now and never would need, so that it might in

time offer them the same functionality those users already had... then I

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

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

You miss one basic principle of free software:
Forks are allowed, so when you don't like the way some software is

developed you can always release a version of the software that is in

your eyes better.
And that's nothing evil, after all each distribution kernel is a fork of

the upstream kernel.
Hey, you can even use the 2.6.16 branch *I* do maintain to avoid what

you claim was an "ethical problem".
And if you don't like 2.6.16 either for whatever reason there's still no

ethical problem but only the technical problem of you not getting your

ass up and doing whatever is "better" in your opinion.
After all, free software is not driven by people whining but by people

doing stuff.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

What a silly thought.  Nobody, I should hope, wants multiple Linuxes

competing and diluting the market.  That's what went wrong with UNIX,

and it's what's wrong with BSD (and what gave Linux a foothold.)  Read
Howling protest is not whining.  The whining comes from those who want

to kill the old driver, which is reported to be used, works well and is

wanted.  It sounds insecure to want to terminate one's competition with

such extreme prejudice.  Let the old driver die of natural causes, if

that's its destiny.  And don't whine if the new can't make it on its own

merits.

--

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.  They're getting it for free, they should at least

give the developers the kindness of a bug report if something is broken...
<insert diatribe about users who just want free-as-in-beer>....

Drivers get better because someone who finds a benefit in them also

finds a problem. They don't get better by developers looking for

intermittent, probably load dependent, bugs which effect eight year old

server hardware which was a low volume item, the developers are unlikely

to have, and which is in use providing services, not on someone's 
Not when drivers are "better" but when a new driver offers some benefit,

be it reliability, capability, etc. When the new driver offers not a

single benefit and the only "feature" is "possible unknown bugs," people

are not going to change, and I don't think forcing people off working

drivers is any more ethical than Microsoft killing XP to force people to

VISTA. Less ethical, actually, because MSFT is looking for profit, and

they make no pretense of caring about the users in any role but revenue 
Insert it right next to the diatribe about developers who think that

because some new feature was a lot of work that Linus *must* put it in

the kernel, or users show show proper respect and gratitude and disrupt

their production hardware to test and debug some new code which offers

zero added functionality on that hardware. If you think downtime is

"free" then you  have not been working in the right environments, or for

the right management.
--

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

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

Been there, done that.  We got a number of boxes that sit there for ages

between reboots and even longer between upgrades.  Deploying Solaris 10 was

like a 2-year process for some of our boxes (when the boxes are running the

Oracle databases that house the enterprise business systems, and your

organizational budget is pushing the $1B/year mark, everybody gets *really*

cautious to avoid a CLM while upgrading... ;)  And we may actually manage to

finally kill off our last AIX 4.3.3 box this quarter (4.3.3 was released all

the way back in Sep 1999, and EOL'ed back in 2004 - don't ask. :)
Of course, the difference is that we *expect* that there's a good chance that

if we try to subject that sort of box to 3 year's worth of updates, there's a

good chance we'll discover that some driver has been EOL'ed or otherwise

problematic on now-ancient hardware...
(And yes, there's a *lot* of risk-management going on centered around "What if

we have to patch Server23 for a critical kernel security issue?".  Of course,

if it was actually *feasible* to blindly upgrade-and-reboot twice a month, the

job could be done by a much less expensive patch monkey, so it's good job

security ;)