News from the staging tree
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:
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:
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:
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 | |
---|---|
Kernel | Development model/Driver merging |
Kernel | Staging tree |
Posted Sep 10, 2009 6:36 UTC (Thu)
by ErikA (guest, #53177)
[Link] (4 responses)
Posted Sep 10, 2009 12:59 UTC (Thu)
by xav (guest, #18536)
[Link] (2 responses)
Posted Sep 10, 2009 23:20 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (1 responses)
You didn't say why that's a problem.
Posted Sep 11, 2009 8:06 UTC (Fri)
by xav (guest, #18536)
[Link]
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.
Posted Sep 11, 2009 0:07 UTC (Fri)
by hmh (subscriber, #3838)
[Link]
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.
Posted Sep 11, 2009 14:21 UTC (Fri)
by zander76 (guest, #6889)
[Link] (5 responses)
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"
Posted Sep 11, 2009 17:21 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (4 responses)
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.
Posted Sep 12, 2009 4:03 UTC (Sat)
by zander76 (guest, #6889)
[Link] (3 responses)
Posted Sep 13, 2009 2:53 UTC (Sun)
by gregkh (subscriber, #8)
[Link] (2 responses)
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
Oh, and as for this driver, Intel told me to drop it, they don't want
Posted Sep 13, 2009 13:25 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Sep 13, 2009 15:48 UTC (Sun)
by gregkh (subscriber, #8)
[Link]
News from 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
News from the staging tree
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
News from the staging tree
News from the staging tree
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]
News from the staging tree
News from the staging tree
News from the staging tree
is trying to interpret the phrase and meaning of every single line.
ask me?
it in the kernel anymore as the team has been disbanded, and they no longer
care about the code.
News from the staging tree
News from the staging tree