Re: removing existing working drivers via staging

From: david
Date: Thu Oct 15 2009 - 15:03:57 EST


On Thu, 15 Oct 2009, Greg KH wrote:

On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
On Thursday 15 October 2009 19:49:32 Greg KH wrote:
On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
On Thursday 15 October 2009 18:47:26 Greg KH wrote:
On Thu, Oct 15, 2009 at 09:39:51AM -0700, david@xxxxxxx wrote:
however, what I think I saw proposed was to move drivers that need to be
'cleaned up', to staging and then dropping them if they don't get cleaned.

What is "proposed" is the following:

- For drivers currently in the kernel tree, that the subsystem
maintainer, for whatever reason, feels is obsolete / broken /
needs major cleaning / wants to get rid of, can be submitted
to the staging maintainer to be moved to the drivers/staging/
directory.

This is insanity and opens a door for various forms of abuse.

What do you mean by this? What kind of "abuse"?

Typical situation:

You have driver for _really_ difficult hardware used by minority of total
users of a given subsystem. Said driver has no major problems except being
f*cking complicated (because of hardware) so it stays in the way of future
changes.

With the current system people making bigger changes have to comprehend
that difficult stuff [*]. This is a good thing in the long-term since it
results in the better overall system understanding, better knowledge of
"DO's and DON'T's" and better users' experience.

Now with the proposed scheme it is sufficient to throw said driver into
staging for few weeks and make future changes. Before users even notice
and complain they are screwed already since bringing the driver back is
no longer possible without big effort (+ subsystem is still evolving)..

But a driver in staging still has to be able to build, api changes are
not able to be ignored in it.

a driver in staging will be able to build, but a driver that was removed after 6-9 months that a user discovered the removal of a year later when they upgraded to a new distro release (say a normal ubuntu release after staying on the old one for the 18 month support period) is likely to need significant work to catch up with kernel changes in the meanwhile.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/