Content-Length: 30497 | pFad | http://lwn.net/Articles/351480/

News from the staging tree [LWN.net]
|
|
Subscribe / Log in / New account

News from the staging tree

By Jake Edge
September 9, 2009

The staging tree has made a lot of progress since it appeared in June 2008. To start with, the tree itself quickly moved into the mainline in October 2008; it also has accumulated more than 40 drivers of various sorts. Staging is an outgrowth of the Linux Driver Project that is meant to collect drivers, and other "standalone" code such as filesystems, that are not yet ready for the mainline. But, it was never meant to be a "dumping ground for dead code", as staging maintainer Greg Kroah-Hartman put it in a recent status update. Code that is not being improved, so that it can move into the mainline, will be removed from the tree.

Some of the code that is, at least currently, slated for removal includes some fairly high-profile drivers, including one from Microsoft that was released with great fanfare in July. After a massive cleanup that resulted in more than 200 patches to get the code "into a semi-sane kernel coding style", Kroah-Hartman said that it may have to be removed in six months or so:

Unfortunately the Microsoft developers seem to have disappeared, and no one is answering my emails. If they do not show back up to claim this driver soon, it will be removed in the 2.6.33 release. So sad...

Microsoft is certainly not alone in Kroah-Hartman's report—which details the status of the tree for the upcoming 2.6.32 merge window—as several other large companies' drivers are in roughly the same boat. Drivers for Android hardware (staging/android), Intel's Management Engine Interface (MEI) hardware (staging/heci), among others were called out in the report. Both are slated for removal, android for 2.6.32, and heci in 2.6.33 (presumably). The latter provides an excellent example of how not to do Linux driver development:

A wonderful example of a company throwing code over the wall, watching it get rejected, and then running away as fast as possible, all the while yelling over their shoulder, "it's required on all new systems, you will love it!" We don't, it sucks, either fix it up, or I am removing it.

Kroah-Hartman's lengthy report covers more than just drivers that may be removed; it also looks at those that have made progress, including some that should be moving to the mainline, as well as new drivers that are being added to staging. But the list of drivers that aren't being actively worked on is roughly as long as the other two lists combined, which is clearly suboptimal.

Presumably to see if folks read all the way through, Kroah-Hartman sprinkles a few laughs in an otherwise dry summary. For the me4000 and meilhaus drivers, he notes that there is no reason to continue those drivers "except to watch the RT guys squirm as they try to figure out the byzantine locking and build logic here (which certainly does count for something, cheap entertainment is always good.)"

He also notes several drivers that are in the inactive category, but are quite close to being merge-worthy. He suggests that developers looking for a way to contribute consider drivers such as asus_oled (Asus OLED display), frontier (Frontier digital audio workstation controller), line6 (PODxt Pro audio effects modeler), mimio (Mimio Xi interactive whiteboard), and panel (parallel port LCD/keypad). Each of those should be relatively easy to get into shape for inclusion in the mainline.

There are a fair number of new drivers being added for 2.6.32, including the Microsoft Hyper-V drivers (staging/hv) mentioned earlier, as well as VME bus drivers (staging/vme), the industrial I/O subsystem (staging/iio), and several wireless drivers (VIA vt6655 and vt6656, Realtek rtl8192e, and Ralink 3090). Also, "another COW driver" is being added: the Cowloop copy-on-write pseudo block driver (staging/cowloop).

Two of Evgeniy Polyakov's projects—mistakenly listed in the "new driver" section though they were added in 2.6.30—were also mentioned. The distributed storage (DST) network block device (staging/dst), which Kroah-Hartman notes may be "dead" is a candidate for removal, while the distributed filesystem POHMELFS (staging/pohmelfs) is mostly being worked on out-of-tree. Polyakov agrees that DST is not needed in the mainline, but is wondering about moving POHMELFS out of staging and into fs/. Since there are extensive changes on the way for POHMELFS, it is unlikely to move out of staging for another few kernel releases at least.

There was also praise for the work on various drivers which have been actively worked on over the last few months. Bartlomiej Zolnierkiewicz was singled out for his work on rt* and rtl* wireless drivers (which put him atop the list of most active 2.6.31 developers), along with Alan Cox for work on the et131x driver for the Agere gigabit Ethernet adapter. Johannes Berg noted that much of Zolnierkiewicz's work on the rt* drivers "will have been in vain" because of the progress being made by the rt2x00 project. But that doesn't faze Zolnierkiewicz:

The end goal of this work has always been having native rt2x00 support for all those chipsets (as have been explained multiple times). If this means that one day we will delete all Ralink drivers in staging in favor of proper wireless drivers -- fine with me.

In the meantime (before clean and proper support becomes useful) Linux users are provided with the possibility to use their hardware before it becomes obsolete.

At least one developer stepped up to work on one of the inactive drivers (asus_oled) in the thread. In addition, Willy Tarreau mentioned that he had heard from another who was working on panel, telling Kroah-Hartman: "This proves that the principle of the staging tree seems to work".

Overall, the staging tree seems to be doing exactly what Kroah-Hartman and others envisioned. Adding staging into the mainline, which raised the profile and availability of those drivers, has led to a fair amount of cleanup work, some of which has resulted in the drivers themselves moving out of staging and into the mainline. Some drivers seem to be falling by the wayside, but one would guess that Kroah-Hartman would welcome them back into the tree should anyone show up to work on them. In the meantime, the code certainly hasn't suffered from whatever fixes various kernel hackers found time to do. Those changes will be waiting for anyone who wants to pick that code back up, even if it is no longer part of staging.


Index entries for this article
KernelDevelopment model/Driver merging
KernelStaging tree


to post comments

News from the staging tree

Posted Sep 10, 2009 6:36 UTC (Thu) by ErikA (guest, #53177) [Link] (4 responses)

I don't see the rush of deprecating drivers once they're in the staging tree.
Let them sit there for a couple of years and see if anyone comes around to pick one up.

News from the staging tree

Posted Sep 10, 2009 12:59 UTC (Thu) by xav (guest, #18536) [Link] (2 responses)

Nope, otherwise staging will be the place for crappy drivers that no one wants to maintain but that people need anyway for their hardware.

News from the staging tree

Posted Sep 10, 2009 23:20 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

Nope, otherwise staging will be the place for crappy drivers that no one wants to maintain but that people need anyway for their hardware.

You didn't say why that's a problem.

News from the staging tree

Posted Sep 11, 2009 8:06 UTC (Fri) by xav (guest, #18536) [Link]

The 'staging' tree is there precisely to avoid dumping low-quality drivers in the kernel. These drivers are in a controlled environment where they are either fixed then integrated in the main tree, or dumped after a while.

If they can stay there indefinately, there will be no motivation to fix them because, well, they're already in the kernel and they kind of work.

News from the staging tree

Posted Sep 11, 2009 0:07 UTC (Fri) by hmh (subscriber, #3838) [Link]

staging drivers:

1) reduce the system stability (they're called "crap" for a reason)

2) give subpar performance/user-experience/functionality

So, if a driver is crap, and it is not doing any progress towards a higher, less crappy state of being, it will be removed.

It is in the rules of engagement for the staging tree, and it is a way to pressure people and manufacturers into improving crap drivers, before they go stale for too long, and decay into the "toxic waste" level.

News from the staging tree

Posted Sep 11, 2009 14:21 UTC (Fri) by zander76 (guest, #6889) [Link] (5 responses)

[QUOTE]:
A wonderful example of a company throwing code over the wall, watching it get rejected, and then running away as fast as possible, all the while yelling over their shoulder, "it's required on all new systems, you will love it!" We don't, it sucks, either fix it up, or I am removing it.
[/QUOTE]

This is one example of linux kernel development being full of themselves. Yeah, sure thats one way to look at it. Another way would be "throw code over wall after spending time getting your boss to let you release the code and move on to what you are suppost to be working on before you get fired!!"

It take a lot of time and effort to convince your boss that releasing code to the linux community is a good thing but they don't want to pay you to work on a linux project when you have other stuff to do. If people like it or can use any of it then great if not ohh well.

To put it briefly, some of us don't work in the open source community or even use open source software at work so there is absolutely NO incentive for our boss to allow us to release anything let alone do continual work on it. Would be nicer if people would accept what it is and that is "hey, thanks for the example code, if someone is interested in working on that they can have a look at what you released"

News from the staging tree

Posted Sep 11, 2009 17:21 UTC (Fri) by martinfick (subscriber, #4455) [Link] (4 responses)

While your perspective is a good one, it does not really apply to the quote above. Sure, it is a great thing when a company releases source code, no matter what!

But if you pay attention to the 2nd half of the quote, it implies an expectation on the part of the releaser, that's the complaint. In other words, no one is complaining that a company released code, they are complaining that certain companies release code and expect it to make it into mainline so that this same company can later benefit from this code being in mainline for future projects (note the: "it's required on all new systems").

This requires a two way interactive model; as others have pointed out, that seems to be the point of the staging tree. The kernel devs do NOT expect the companies to do all the work on their own (that's why it goes in the staging tree, to get kernel devs involved). But this also means that the kernel devs have not yet taken up maintainership of the code since it is not yet in mainline. They expect the company to be involved working with the devs to bring it up to par. Once it is up to par, I suspect that it is more acceptable to rely on the kernel devs to keep it up to date with the changing mainline kernel, but not before.

News from the staging tree

Posted Sep 12, 2009 4:03 UTC (Sat) by zander76 (guest, #6889) [Link] (3 responses)

After reading the quote a few times I see your point. I guess it depended on how you read "Its required on all new systems". I read it more alone the lines of the hardware has changed so if you want to support the new hardware you can make it work. After re-reading it I can see that it can be taken as "We need it on all our new systems so merge this".

News from the staging tree

Posted Sep 13, 2009 2:53 UTC (Sun) by gregkh (subscriber, #8) [Link] (2 responses)

My word, I feel like this is 8th grade poetry class, where everyone
is trying to interpret the phrase and meaning of every single line.

That was a summary of over 40 drivers, and was a very long message. If anyone wants any specific clarification, did anyone think to actually
ask me?

Oh, and as for this driver, Intel told me to drop it, they don't want
it in the kernel anymore as the team has been disbanded, and they no longer
care about the code.

News from the staging tree

Posted Sep 13, 2009 13:25 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

Would the code have done anything useful were it fixed up, I wonder?

News from the staging tree

Posted Sep 13, 2009 15:48 UTC (Sun) by gregkh (subscriber, #8) [Link]

Perhaps, try it out, it's not like it is hidden anywhere...


Copyright © 2009, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/351480/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy