Microsoft contributes Hyper-V drivers to the kernel [LWN.net]

Microsoft has joined the community of Linux kernel contributors with the addition of its Hyper-V drivers, soon to appear in linux-next. "These drivers are to enable Linux to work better when running as a guest on top of the Hyper-V system. There is still a lot of work to do in getting this into "proper" mergable state, and moving it out of the staging directory..."

to post comments

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 16:17 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (16 responses)

Running Linux as a guest on a Windows hypervisor?

Well, for the sort of people who would like that sort of thing, this is sure to be the sort of thing that that sort of people will like.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 16:44 UTC (Mon) by drag (guest, #31333) [Link] (15 responses)

Typical Windows shop will automatically favor the Microsoft alternative to any technology available. It's a automatic and ingrained into their 'IT' psychological makeup.

So despite the fact that Hyper-V is inferior to solutions like Xen, Linux-KVM, or anything out of Vmware it does not really matter. Since it has the 'Microsoft' name, it integrates into Active Directory and into Windows Server it will automatically become very popular.

This is a big step forward for Microsoft. Not only is it GPLv2 code coming out of Microsoft it should massively improve the performance and integration when running Linux systems in Hyper-V and make it just that much cheaper and easier for people to start using Linux at their businesses*.

* that is unless the anti-M$ brigade comes out and makes enough fuss that it gets stripped out of the kernels in distros because of vague worries about unspecified patent threats.

Patent threats?!

Posted Jul 20, 2009 16:56 UTC (Mon) by vonbrand (guest, #4458) [Link] (14 responses)

Microsoft GPLv2'd this, this means they can't turn around and assert any of their patents against this particular code (or derivatives).

Besides, it would make very little sense... (OK, OK; I've followed the SCO saga, so I know sometimes logic has extremely little impact on company behaviour...)

Patent threats?!

Posted Jul 20, 2009 17:15 UTC (Mon) by davi (guest, #18853) [Link] (13 responses)

Microsoft GPLv2'd this, this means they can't turn around and assert any of their patents against this particular code (or derivatives).

Unfortunately all that patch and the Linux kernel itself is GPLv2 in fact, not GPLv3. So it is because it is not protected against patent attacks.

I hope the GNU Hurd kernel will be licensed under GPLv3 _or later_ so we do not have this problem in future.

See Hunt down non-GPLv3-compatible code

Patent threats?!

Posted Jul 20, 2009 17:30 UTC (Mon) by drag (guest, #31333) [Link] (9 responses)

> Unfortunately all that patch and the Linux kernel itself is GPLv2 in fact, not GPLv3. So it is because it is not protected against patent attacks.

GPLv2 patent licensing is 'implicant', not 'explicit' like it is under the GPLv3. Microsoft is given you permission to use the code under the terms of the GPL and as long as you use it under those terms then you'll be fine.

If I gave you a bunch of code, said your allowed to use it on a commercial product, then after you released the product turn around and sue you for patent violations based on the code I gave you... then that is something that would not stand up in court.

> I hope the GNU Hurd kernel will be licensed under GPLv3 _or later_ so we do not have this problem in future.

It has been under development for 19 years and has only managed to achieve the most basic compatibility with real computers.. at which point it was scrapped and started over again with a new Microkernel core. Started off with Mach, then onto L4, then possibly onto Coyotos (too bad Microsoft bought out the developer for that Microkernel) and possibly other L4 variants or Viengoos thingie.

I think that at point we have a better chance that USA will dissolve it's patent system then HURD ever being competitive with Linux.

Patent threats?!

Posted Jul 20, 2009 17:46 UTC (Mon) by davi (guest, #18853) [Link] (5 responses)

> > Unfortunately all that patch and the Linux kernel itself is GPLv2 in fact, not GPLv3. So it is because it is not protected against patent attacks.
>
> GPLv2 patent licensing is 'implicant', not 'explicit' like it is under the GPLv3.

I presume you mean "implicit".

There is no implied patent license in GPLv2. Claiming the GPLv2 has a patent license is wishful thinking. I think you are misreading section 7 of the GPLv2.

Patent threats?!

Posted Jul 20, 2009 18:33 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

The authors of the license disagree with you on that

http://www.gnu.org/licenses/rms-why-gplv3.html

"GPLv3 also provides for explicit patent protection of the users from the program's contributors and redistributors. With GPLv2, users rely on an implicit patent license to make sure that the company which provided them a copy won't sue them, or the people they redistribute copies to, for patent infringement."

Patent licenses

Posted Jul 20, 2009 19:35 UTC (Mon) by man_ls (guest, #15091) [Link]

If Microsoft starts distributing the Linux kernel, things could indeed take an interesting turn of events: by distributing VFAT code they would be giving an implicit patent license to all Linux users. I bet they have already found this, so they will probably not distribute it as a whole.

Patent threats?!

Posted Jul 20, 2009 19:44 UTC (Mon) by davi (guest, #18853) [Link]

You seems right about "implicit"! I was mistaken, sorry.

Patent threats?!

Posted Jul 20, 2009 18:35 UTC (Mon) by drag (guest, #31333) [Link]

> I presume you mean "implicit".

Yes, Thank you.

Patent threats?!

Posted Jul 20, 2009 23:17 UTC (Mon) by SEMW (guest, #52697) [Link]

> There is no implied patent license in GPLv2. Claiming the GPLv2 has a patent license is wishful thinking.

Not only does the FSF disagree with you, as rahulsundaram points out above, but so did an independent legal firm (Fenwick & West LLP), who concluded that: "...it is reasonable to conclude that the implied license defense is available and tenable for a defendant in a patent suit involving software released under the GPL [v2.0]".

Source: www.fenwick.com/docstore/Publications/IP/potential_defenses.pdf

Patent threats?!

Posted Jul 20, 2009 22:28 UTC (Mon) by Max.Hyre (subscriber, #1054) [Link]

[...] that is something that would not stand up in court.

Maybe not, but the workings of the U.S. judicial system guarantee that it could take years, and (optimistically) tens of thousands of dollars. For many people, the difference between this and losing is negligible.

Hurd facts (was: Patent threats?!)

Posted Jul 21, 2009 2:49 UTC (Tue) by antrik (guest, #40693) [Link] (1 responses)

> It has been under development for 19 years and has only managed to achieve the most basic compatibility with real computers..

Indeed, hardware support in the Hurd is presently extremely poor. This could be fixed in a reasonable amount of time though, if people cared...

(Most do not care at this point, as they prefer running it in VMs anyways.)

This is *not* the biggest challange.

> at which point it was scrapped and started over again with a new Microkernel core. Started off with Mach, then onto L4, then possibly onto Coyotos (too bad Microsoft bought out the developer for that Microkernel) and possibly other L4 variants or Viengoos thingie.

It was *not* scrapped. What did happen is that *some* developers started exploring new designs based on different microkernels.

Hurd/L4 was first, and went all the way up to a half-working prototype (remember the "banner" news?... ;-) ), before the developers realized that L4 is not suitable after all...

Then they mused about some other kernels that seemed more suitable -- mostly Coyotos. But that turned out problematic too, and was abandoned before any code got written. (*Long* before Shapiro gave up on Coyotos and went to Microsoft.)

Finally, they concluded that microkernel design and system design are too closely interlocked to reuse someone else's kernel -- creating a good system architecture requires a microkernel specifically designed for it. Viengoos is essentially the consequence of this realization.

All this time, other people continue to improve the existing Hurd implementation on top of Mach. It is totally unaffected by these experimentations -- aside from many people being confused and incorrectly believing it was abandoned...

> I think that at point we have a better chance that USA will dissolve it's patent system then HURD ever being competitive with Linux.

Nobody in his right mind would seriously expect the Hurd to become "competitive" with Linux in terms of performance, hardware support etc.

It is quite realistic though to become *good enough*, so that interested people can use it without problems, if they are willing to forsake a little performance etc. in favor of other properties. Some might prefer it because of the GPLv3 option. Some might prefer it because of the possibilities offered by the different architecture.

That's all we really hope for -- world domination is *not* a must to make the project worthwhile...

It's non-started like openbsd then

Posted Jul 21, 2009 7:22 UTC (Tue) by khim (subscriber, #9252) [Link]

Nobody in his right mind would seriously expect the Hurd to become "competitive" with Linux in terms of performance, hardware support etc.

Why the hell not?

It is quite realistic though to become *good enough*, so that interested people can use it without problems, if they are willing to forsake a little performance etc. in favor of other properties.

If we are talking about "a little performace etc" it means the thing is competive. Being competive does not mean "being better by all metrics". It means "being better in some areas while not too much worse in other ones". A lot of people are ready to concede 10% for better security or flexibility, for example, but very few are ready to get 10x slowdown... Heck - that's why we've switched from a.out to elf many years ago!

Some might prefer it because of the GPLv3 option.

Microsoft works on that but then it's hard even for Microsoft...

Patent threats?!

Posted Jul 20, 2009 21:53 UTC (Mon) by kragil (guest, #34373) [Link] (2 responses)

The Slashdot Sam Ramji says:

Our use of the GPLv2 license, as requested by the Linux community, means we will not charge a royalty or assert any patents covering the driver code we are contributing.

Sam
sramji@microsoft.com

http://news.slashdot.org/comments.pl?sid=1308785&cid=...

Patent threats?!

Posted Jul 20, 2009 22:32 UTC (Mon) by Max.Hyre (subscriber, #1054) [Link] (1 responses)

[...] we will not charge a royalty or assert any patents

Can I have that in writing, please?

Patent threats?!

Posted Jul 20, 2009 23:23 UTC (Mon) by SEMW (guest, #52697) [Link]

>> [...] we will not charge a royalty or assert any patents
> Can I have that in writing, please?

Sure, here you go: www.gnu.org/licenses/gpl-2.0.html .

Royalties are obvious. The implicit patent license given by releasing code under GPL 2 is less so, but is discussed in the thread above.

virtio

Posted Jul 20, 2009 16:23 UTC (Mon) by hollis (subscriber, #6768) [Link]

I guess that means they're not using virtio then...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 16:32 UTC (Mon) by Trelane (guest, #56877) [Link] (4 responses)

greg k-h has a blog post on it too: http://www.kroah.com/log/linux/microsoft-linux-hyper-v-dr...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:03 UTC (Mon) by AlexHudson (guest, #41828) [Link]

"I've been working with the developers at Microsoft for a while now trying to make this happen"

More grist to the anti-Novell hysterics :)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 21:10 UTC (Mon) by proski (guest, #104) [Link] (2 responses)

Q: Why release the code?
A: Because we have utilized Linux code, Microsoft has an obligation to open source the device drivers. This is the process outlined by the Linux community.

Either they don't understand GPLv2, or they are going to distribute Linux!

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 21:17 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

they are distributing drivers for linux. those drivers are derivitives of the kernel, so to release those drivers they need to do so under GPLv2

nothing says they need to distribute the entire kernel.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 0:07 UTC (Tue) by proski (guest, #104) [Link]

Cunning bastards :-(

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 16:32 UTC (Mon) by MisterIO (guest, #36192) [Link] (3 responses)

So now they can publicize the fact that even Linux makes use of Microsoft's technology.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 16:37 UTC (Mon) by Trelane (guest, #56877) [Link]

If it's GPL'ed I don't care if the code came from $evil_historical_person. (Well, in both cases, I'd rather it be checked extensivly for "accidental" security holes ;)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:37 UTC (Mon) by nhippi (subscriber, #34640) [Link] (1 responses)

And we can publisize that even Microsoft contributes to Linux - under GPLv2.

Now if we can just get them to contribute vfat drivers..

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:16 UTC (Mon) by Trelane (guest, #56877) [Link]

Or distribute the kernel with the drivers innit...

Patent license?

Posted Jul 20, 2009 16:50 UTC (Mon) by kripkenstein (guest, #43281) [Link]

IANAL, but I presume this means that Microsoft is licensing its relevant patents, as per the GPL2 patent clause. So if Microsoft has any patents on Hyper-V, those might not be an issue any more.

Nice to have I guess.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:19 UTC (Mon) by whacker (subscriber, #55546) [Link] (4 responses)

Let me be the first to congratulate Microsoft. Given their history of public statements about the GPL, this is a HUGE step forward.

Well Done! :)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:33 UTC (Mon) by drag (guest, #31333) [Link] (3 responses)

Yes. This is a good thing.

Plus they are working with the Linux kernels to get it integrated into the vanilla kernel.

They could of just used their own programmers to hack together a network, balloon, and block driver for Linux and had no intention of getting it into the kernel. Even if they did license it under the GPL then their programming style and approach could of easily kept it rather 'proprietary' in it's effect.

Similar how the 'nv' open source driver for Nvidia cards works.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 23:01 UTC (Mon) by ariveira (guest, #57833) [Link] (2 responses)

Well they are integrating those driver to avoid a lawsuit if i read
what Hamminger says correctly

http://linux-network-plumber.blogspot.com/2009/07/congrat...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 8:15 UTC (Tue) by skitching (guest, #36856) [Link] (1 responses)

Yes. Reading the linked articles reveals an interesting story.

It appears that a company called Vyatta (www.vyatta.com) has their own operating system for routing/firewall type stuff. This kernel is derived from Linux but they appear to have then added hyper-v support for their OS, so that people can run the vyatta kernel as a guest on windows.

They have then been shipping their kernel, and have made the source available. But the combined vyatta/microsoft-hyper-v code had never been correctly licensed. So when someone noticed this, Vyatta was in deep trouble. Technically, they would have to pull their product from the market, as they are shipping mixed GPL/proprietory code.

Microsoft have saved Vyatta's skin by agreeing to license their hyper-v code under the GPL (possibly after a payment from vyatta to MS?).

So it is no surprise that the code is in an ugly state; MS was presumably not expecting to have to release this. But it is still a step forward that they have done so. If they really do put some effort into cleaning up the code so it can move from staging to kernel proper, that would be great. It's not clear to me whether they will actually do that though; their primary motivation is obviously to allow Vyatta to continue to ship their product.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 10:42 UTC (Tue) by skitching (guest, #36856) [Link]

A correction to my comment..

I've read a little bit more, and it now appears that the drivers themselves are actually from the "Microsoft Linux Integration Components" (LIC) project. It's not clear from the articles whether vyatta ships these components, or whether a user was trying to add them into a vyatta install.

http://www.microsoft.com/downloads/details.aspx?FamilyID=...

It seems that it is the Microsoft LIC product that incorrectly combined GPL and proprietory source.

The articles hint that RedHat and SuSE have been including the LIC drivers for some time. Anyone know if this is correct? I personally doubt it..

See:
http://linux-network-plumber.blogspot.com/2009/07/congrat...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:30 UTC (Mon) by einstein (subscriber, #2052) [Link] (4 responses)

As I've often said before, microsoft loves open source - as long as it's running on top of microsoft windows.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:37 UTC (Mon) by drag (guest, #31333) [Link] (3 responses)

Yes. But if GPL is a virus, then OSS is a cancer for proprietary companies.

Once large customers get a taste of the freedom and the advantages of having a deterministic control over their own software tools.. then they'll start wanting more, and then demanding more. A company that does not meet the needs, requirements, and desires of their customer base are going to loose that base.

I wouldn't be surprised that in a couple years Microsoft will start open sourcing some very substantial bits of their software stack. Especially if they figure out how to use Linux to their advantage.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:13 UTC (Mon) by einstein (subscriber, #2052) [Link] (2 responses)

Well that's a nice thought, but one has to keep in mind that their number one goal is remaining firmly seated in a position of control, and making sure nobody can threaten their monopoly.

It's inevitable IMHO that as they continue their conquest of the open source world, they will begin to argue for efficiency: "Sure, you can continue to run your open source apps on linux under microsoft windows, but it would be a lot simpler and more efficient to just cut out the middle man and run your open source apps directly on microsoft windows!"

Mark my words - you read it here fist.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:42 UTC (Mon) by drag (guest, #31333) [Link]

> It's inevitable IMHO that as they continue their conquest of the open source world, they will begin to argue for efficiency: "Sure, you can continue to run your open source apps on linux under microsoft windows, but it would be a lot simpler and more efficient to just cut out the middle man and run your open source apps directly on microsoft windows!"

Well yes. That is what they are doing, it's pretty obvious. For example they pay money to Apache and PHP folks and have worked to make PHP support Windows much better then it did in the past.

> Well that's a nice thought, but one has to keep in mind that their number one goal is remaining firmly seated in a position of control, and making sure nobody can threaten their monopoly.

Well their number one goal is to keep making money, and they probably do see that protecting their hegemony is critical to that.

But times change. It may become advantageous for Microsoft to stop competitors by starting to have a Linux distro of their own someday. :)

Microsoft's goals

Posted Jul 20, 2009 23:08 UTC (Mon) by Max.Hyre (subscriber, #1054) [Link]

[K]eep in mind that their number one goal is remaining firmly seated in a position of control, and making sure nobody can threaten their monopoly.

Keep in mind that their number one goal is to make the maximum amount of money. This is a requirement of being a publicly-owned corporation in the U.S. If they could make noticeably more profit by putting Windows 7 under GPL v3, they'd do it.

So long as they're the almost-monopoly they are, though, it's unlikely that's how to increase profits.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 17:45 UTC (Mon) by jengelh (subscriber, #33263) [Link] (1 responses)

Man, those patches surely need a cleanup o_O

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 4:43 UTC (Tue) by jgg (subscriber, #55211) [Link]

Yah, for sure.. WTF? How did this come about?

It looks like someone took some Windows SDK code for the Windows drivers and bashed it till it compiled inside Linux and then probably used it as the driver kit that was distributed with SuSE? Then someone else realized that was pretty pointless and decided it needed to be in mainline so re-licensed the entire SuSE driver kit..

Man.. I donno, might have been easier to start with a spec than this. Good luck to all involved.

Now, the *real* prize from this is to develop a KVM/Xen server side so that we can use the good MS para-virtualizated net and block drivers in Windows!! The current open solutions are pretty bad in comparison.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:21 UTC (Mon) by marduk (guest, #3831) [Link] (1 responses)

Do these drivers utilize binary blobs (a la Nvidia) or are they actually... well... drivers?

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:36 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

They are real drivers and not just binary blobs.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:34 UTC (Mon) by trasz (guest, #45786) [Link] (6 responses)

I was going to write that this will be soon followed by the usual FUD about software patents, but _obviously_ I'm already late. ;-)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 18:48 UTC (Mon) by johnflux (guest, #58833) [Link] (5 responses)

Is it really FUD that Microsoft might sue over software patents, given that they are _currently_ suing over VFAT software patents?

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 19:20 UTC (Mon) by drag (guest, #31333) [Link]

I think that it's worth considering.

Although I'd wish people would take a bit more of a consideration when understanding the scope of the problem with software patents.

For this example... The drivers are, I am guessing, are I/O drivers that implement some paravirtualization features to increase the performance and compatibility of running Linux in Hyper-V.

Well those patents that Microsoft may possibly have that covers some of the Hyper-V paravirt features may apply to the Linux driver code. But it's pretty likely that any patents would apply to paravirt techniques used in the Linux-KVM stuff or in Xen stuff.

So getting Microsoft to contribute code to the kernel means that not only are they probably sacrificing much of their ability to go after paravirt features used in KVM or Xen, it is quite likely a gain for Linux kernel in other ways.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 19:27 UTC (Mon) by iabervon (subscriber, #722) [Link]

Microsoft would put itself in a particularly tenuous legal position and likely destroy their ability to sell software to companies with legal departments if they distributed code under some license and then sued people for patent infringement for using that code under that license. Can any Microsoft software be used at all without violating a Microsoft patent which the purchaser has not explicitly granted a license to? (Particularly as the licenses for new software may be written too soon to have explicit references to new patents the software uses.)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 17:36 UTC (Tue) by trasz (guest, #45786) [Link] (2 responses)

IBM holds several patents applicable to Linux (RCU, some JFS stuff) and nobody cares, even though they forced PostgreSQL guys to remove some stuff because of some patent IBM holds. But of course IBM (which was, btw, the first large company to use FUD as a marketing strategy, against Amdahl - oh, and there is the Platform Solutions case) is nice and Microsoft is evil.

;->

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 24, 2009 14:15 UTC (Fri) by Los__D (guest, #15263) [Link] (1 responses)

Just because Amdahl coined the term, it doesn't think it's the first time.

I'm pretty sure that FUD itself is millennia older than computing...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 24, 2009 14:16 UTC (Fri) by Los__D (guest, #15263) [Link]

That was one comment I posted way too quick, sorry about that.

"I don't think it was the first time"

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 23:09 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (5 responses)

So...
does this mean that in the ranking of corporate sponsors of linux kernel contributions that Microsoft will likely show up as a higher ranking that Canonical in next year's linux kernel report?

-jef

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 20, 2009 23:22 UTC (Mon) by kragil (guest, #34373) [Link] (1 responses)

Certainly.

Canonical does not produce (virtual) hardware that needs drivers.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 3:04 UTC (Tue) by jmm82 (guest, #59425) [Link]

I subscribed to the Canonical kernel-dev list about 8 months ago and it was definitely not what I expected. It was unclear for the first few weeks what the list even did. It mostly consists of cherry picks and one line patches to fix sound drivers and such. The list is boring to say the least(as an outsider) and there is very little non-Canonical employed people contributing to the list, but isn't there a old saying that goes, "It's the little things that matter most." ;)

I will say I did post a comment to the list once and received a nice response from Tim Gardner, who appears to be in charge of kernel dev. Also, I have been using Ubuntu for 2 years and have minimal complaints and yes sometimes it can be *too* user friendly, but that comes with the territory.

One comment about this article:

Beware of Greeds bearing gifts.

--
John

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 7:05 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Jef,

So your OCD of replying to anything Canonical related has degenerated further into finding ways to slight Canonical in comments on unrelated stories?

--paulj

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 16:21 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (1 responses)

It was meant more to make everyone uncomfortable. I think a lot of people are all going to feel uncomfortable being put in a situation where they might need to overtly praise Microsoft for contributions if they climb up to be a notable ranking in the list of corporate sponsored contributions to the linux kernel. I'd much rather see Canonical stay ahead of MS in the regard, but I don't make Canonial's staffing decisions. The irony is, Canonical stands to benefit with better hyper-V support in the mainline kernel. I wonder if there is any money to be made supporting Ubuntu guests running on hyper-v. So we might even find that Shuttleworth will have a compelling reason to praise Microsoft for their kernel contributions. Man that would be really uncomfortable to watch happen.

-jef

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 22:42 UTC (Tue) by kragil (guest, #34373) [Link]

http://mdzlog.alcor.net/2009/07/21/launchpad-and-microsoft/

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 7:25 UTC (Tue) by BackSeat (guest, #1886) [Link] (3 responses)

I constantly read on LWN how contributors have to work with the kernel developer community to get code into the kernel, how the architecture should be discussed, how the code should be released little and often, and so on.

Can someone explain to me why Microsoft have apparently worked with only one kernel developer, albeit gk-h, and somehow managed to release 20K LOC into the kernel?

I'm not passing judgement on the work done, merely expressing surprise that a sizable code chunk can apparently appear in one lump, and that is apparently OK.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 8:00 UTC (Tue) by skitching (guest, #36856) [Link] (1 responses)

This code hasn't gone into the kernel "core" yet; it has just gone into the "staging" directory of the kernel code repository. Just about any code can be put into "staging" as long as it is correctly licensed and Greg thinks there is some point in having it there. Staging code is not compiled by default when building the kernel, and if someone does deliberately include "staging" code when building a custom kernel then the "crap" taint flag is set in the kernel and bugreports will generally be ignored.

The idea is that once the code is in the "staging" directory it is easier for people to work on so it can eventually become an official & supported part of the kernel.

Some distributions do include a few specific drivers from the staging directory, where the hardware is in use but no "approved" driver yet exists. I doubt anyone will include the hyper-v code in their distribution kernels for a long while though...

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 22, 2009 9:22 UTC (Wed) by Kamilion (subscriber, #42576) [Link]

@BackSeat, Replying to skitching for thread informativeness / clarity.

It should also be noted, the commits were the original code submissions from MSOSS, upon which many more cleanup commits were laid on top of by Greg and Co.
http://thread.gmane.org/gmane.linux.kernel/867190
http://www.kroah.com/log/linux/microsoft-linux-hyper-v-dr...

This is so all code is attributed to their correct respective authors, and shows the true power of open source -- not only do you get the current source, you also get the previous states, and all the information that carries with it.

You get to watch the process of Microsoft's code getting cleaned up and vetted. This is how it should be. This is how it must be -- think of our future digitally-inclined offspring, and how they will view 'history'. Shall it be an opaque black box of 'X happened.' or a transparent 'Here's thirty layers of wiki-depth, choose your interest level.' history? I prefer the latter. And http://simple.wikipedia.org/wiki/Category:Computer_science is a good start, and addictive! Help it grow!

Celebrate it. Let it be known, Microsoft is changing, just like IBM and Intel did after understanding and embracing linux and open source.

Community can make a difference. Let's show them how much, and welcome them to *our* community. They're beginning to listen. Let's not disappoint them.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 19:36 UTC (Tue) by jgg (subscriber, #55211) [Link]

Drivers tend to go in alot easier without the architecture discussion stuff. As long as the driver looks more or less like kernel code and isn't hugely flawed there isn't too much trouble. Ultimately broken drivers only affect people with that hardware. I suspect it will be a lot less than 20kloc once it is in 'kernel style'.

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 21, 2009 8:28 UTC (Tue) by Schnouki (subscriber, #54571) [Link] (1 responses)

Hmmm, didn't Linus once say If Microsoft ever does applications for Linux it means I've won ? :)

Microsoft contributes Hyper-V drivers to the kernel

Posted Jul 22, 2009 11:15 UTC (Wed) by SEMW (guest, #52697) [Link]

Maybe so, but isn't so much an application for Linux as it is Linux as an application (i.e. virtualized on top of Windows). The victory is sadly not so clear cut...