Re: [GIT PULL] Squashfs pull request for 2.6.29

[Greg KH]

On Thu, Jan 22, 2009 at 05:50:26PM -0500, Kyle McMartin wrote:
> Playing devil's advocate here...
> 
> On Thu, Jan 22, 2009 at 01:58:17PM -0800, Greg KH wrote:
> > > * The fallout of staging is already starting to drift into distros.
> > >   Within a week of Fedora shipping a kernel that had staging/
> > >   we had requests to enable drivers from it.
> > >   And of course, those drivers were garbage.
> > >   This is only going to increase as time goes on.
> > 
> > That's up to you as a distro to handle, not much I can do there.
> > 
> > But, if you want a recommendation, some of the drivers in staging came
> > from the Fedora kernel tree, so you should be enabling them :)
> > 
> 
> Just at76, I think.

Yes.

> > What is wrong with it?  Bugs are getting fixed, people are getting use
> > out of their hardware (hell, Linus is even using one of the drivers),
> > and lots of developers are cutting their teeth on helping out.
> > 
> 
> Why does it need to be upstream for someone to cut their teeth helping
> out?

Because people don't know where to look if it is out-of-the tree.
Seriously, if it can't be easily found, it's not fixed up.  Proof of
that is the hundreds of out-of-tree drivers that I have found over the
past months.

> > If you don't like it, just disable it in your kernel packages, or
> > instantly close out the bugs.  The drivers in staging has already helped
> > out some distros by virtue of including newer drivers than they were
> > mistakenly using at the time (Ubuntu, I'm looking at you...)
> > 
> > And again, it's helped out users, which is the most important thing
> > here.
> > 
> 
> What concerns me is the precedent this sets. If "getting something
> upstream" now means "getting something into staging" then we've failed
> our users since there's no longer any motivation for a vendor to invest
> in all but the most cursory work on a Linux driver.

Woah, you are changing the conversation here totally.

This has nothing to do with "put pressure on a vendor to get their code
into upstream so that a distro will enable it."  We have vendors today
working with the staging tree to get their code cleaned up better to get
it into mergable shape to move over to the main portion of the kernel
tree.

Other vendors throw us code and run away.  We handle that as well, by
doing the work on our own, taking our time.  While that cleanup happens,
users can use their hardware with Linux without having to find the
latest version of a driver on a random google code site, and figure out
how to patch things to handle api changes that have happened since then
(true story for one of the drivers in staging right now.)

> I think we have higher standards to live up to than that.

The staging tree has NOTHING to do with our coding and acceptance
standards.  And anyone that thinks otherwise is totally mistaken.

> (I also think TAINT_CRAP is kind of an insulting name for things which
> are really Linux-targetted features that just haven't had thorough
> enough review. Evgeniy Polyakov's work comes to mind... it's really
> comparing apples to a bunch of festering pieces of turd.

It was his choice to put the code into there, I'll let him handle the
mental issues of having that taint flag associated with it for a few
releases :)

> In summary, I don't know, this is one of those damned if you do, damned
> if you don't paradoxes. ;-) But if you suck in a driver that barfs all
> over your filesystem, because it was allowed to be turned in with zero
> review, are you going to be the one to tell the user "ha ha, sucks to be
> you?" I sure wouldn't want to be.

I'll take responsibility if such a thing happens.  Fear of such a thing
is no reason to prevent users from having their hardware work properly
with Linux.

Again, I'll point to Linus's laptop that now works properly due to the
drivers/staging/ tree as a very visible example of this effort actually
working properly.

thanks,

greg k-h
--
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/