Greg Kroah-Hartman Gripes About Microsoft's Linux Contribution; MS Renews Effort 213
dp619 writes "Microsoft's developers were missing in action after the company donated GPL-licensed drivers to the Linux kernel community in July, leaving significant work to the Linux community, according to Linux driver project lead and Novell fellow Greg Kroah-Hartman. The company rekindled its involvement after Kroah-Hartman published a status report this week. Kroah-Hartman said that other companies were also laggards in Linux development, and that Microsoft's lack of involvement was nothing out of the ordinary."
Not shocked... (Score:4, Informative)
"hv (Microsoft Hyper-V) drivers. Over 200 patches make up the massive cleanup effort needed to just get this code into a semi-sane kernel coding style (someone owes me a bit bottle of rum for that work!) 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..."
In other words, there is some coding to do. Did the Kernel devs coordinate with the managers at MS to ensure resources would be available to work on these patches? (200 patches is not a lot in my opinion. I have a minor patch coming out on the 21st for my in-house system with 2000+ users and it has over 300 fixes.)
I wonder if there was a minor miscommunication...
Cool!
Re:Kinda funny. (Score:5, Informative)
A little credit where it's due (Score:3, Informative)
Two thirds of the summary are lifted directly from the sdtimes link...
Re:How did it make it into the kernel in that stat (Score:5, Informative)
This is for the drivers/staging tree, which is specifically set aside for drivers that don't meet normal code standards but where the intent is to bring them up to par for merging into the "real" tree.
Re:How did it make it into the kernel in that stat (Score:3, Informative)
Re:Thanks (Score:3, Informative)
Well, for one thing, most corporations that contribute code do so so that Linux will work better with their hardware. That's why a lot of the code comes from companies like Intel. As a Linux user with an Intel CPU, that makes me want to buy more Intel CPUs in the future.
MS isn't a hardware company, it's a software company, and it competes directly with Linux.
Anyway, other than this, it really isn't different, but several posters here are acting like it's some kind of useful contribution to Linux. It's not. It's only useful for MS customers running Hyper-V who want to run Linux on top of that.
Just like it's incumbent on other kernel contributors to jump through the hoops necessary to make their code meet the maintainers' standards to be merged into the mainline kernel, MS has to do the same. They can't just dump the code on them and expect them to do all the work. Other companies already do it this way, because they want the code merged into the mainline, for the benefit of their customers. If MS doesn't do this, it's their customers who will suffer, not the Linux community at large.
It's not like they're contributing something that's generally useful to most Linux users, like a codec or a font, or a filesystem. So stop acting like it is.
Invisible downmodded posts (Score:2, Informative)
Flame (Score:5, Informative)
You think this constitutes "publicly flame"ing Microsoft? He's just asking them to step it up and contribute. He's much harder on others in that list. It also doesn't seem like he went out of his way to be interviewed. It sounds like he just responded to a few questions that a reporter put to him. "Unfortunately" and "so sad" do not, of themselves, constitute a flame.
Here are a few other choice passages: (these may be interpreted as weak flames)
heci 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.
me4000 and meilhaus They work on the same hardware, and they duplicate the existing COMEDI drivers. Someone thinks that custom userspace interfaces are fun and required. Turns out that being special and unique is not what to do here, use the COMEDI drivers instead. These will be removed. Heck, I'll go remove them for .32, there is no reason these should still be around, 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.)
rspiusb A weird, very expensive camera, from a company that does not want to release the specs, and wants custom userspace interfaces. The code hasn't built since the 2.6.20 days. I'll go delete it now from .32, it doesn't deserve to live as no one cares about it, least of all, the original authors of the code :(
In other words: "Though it seems that he has the generosity to not publicly flame them unlike Microsoft." is pure hogwash... on both counts.
Re:Thanks (Score:3, Informative)
Ever heard of back ports? Redhat does this quite a lot. New drivers into their own kernel tree. Redhat's latest 2.6.9 kernel in RHEL4 is way different to the one Linus released all those years ago.
Re:Except they're here to teach you to fish (Score:5, Informative)
So you're complaining and threatening to remove the drivers in the next release unless they commit resources in perpetuity to maintaing the drivers vs. *your* code base.
I don't think that's the situation. The drivers currently only exist in the -staging tree. That is far different than Linus' official tree. The -staging tree is home to driver code that does not meet the standards of Linus' tree, and it's purpose is to assist the maintainers of the code to increase its quality such that it can be included in Linus' tree. MS is not being asked to "commit resources in perpetuity," but merely to get the code up to the state where it can be included in Linus' kernel tree.
This is really a stupid demand on your part;if the kernel level APIs (what Sun calls their DDI/DKI - Device Driver Interface/Device Kernel Interface) in Linux were stable and not such a moving target, you could just forget the drivers and they'd keep working indefinitely.
See above. Once the driver is included in the kernel proper, the kernel developers themselves fix drivers when API's change. That's one of the primary benefits of being included in the kernel proper. If you're developing driver code and just dropping it on some corner of the web, then You're Doing It Wrong.
Re:Thanks (Score:3, Informative)
Don't be stupid.
When Intel contributes a patch, they go through the required process necessary to make the patch meet the maintainers' standards. I actually did this a couple times when I worked at Intel.
If MS isn't going to do the work necessary to make their patches meet the standards, then it shouldn't be merged. I'm actually a little disappointed that they merged it in at all before going through this process fully.
It hasn't been merged to drivers/ proper, only drivers/staging/. This is the normal procedure these days for subpar driver code: it gets merged to staging/ in the hopes it will be cleaned up and can be merged to mainline proper.