[Announce] Microsoft Hyper-V drivers for Linux

Microsoft recently has been releasing a surprising amount of open source but I think this the first open source thing explicitly released to Linux let alone the kernel. I hope this is not the last time either. Kudos Microsoft.

I don't think it has been merged into mainline yet. Does anyone know in what branch this source code exists? I'd like to see how Microsoft kernel code looks like.

I never seen Linux kernel code in that style. The coding style is very similar to WIN32.

Looks like it needs a lot of work too. I know someone is going to accuse me of being anti-Microsoft, but the code really doesn't look very professional. Especially all the commented out code, hasn't Microsoft learned to use source control by now?

Maybe I am expecting too much. Obviously Microsoft is inexperienced in this whole Linux kernel thing, so you can't really expect them to put out a masterpiece. From my experience it seems I am one of the few people who actively use comments for commenting alone.

I think Novell is probably going to end up having to clean up their code before it gets into the main tree.

Microsoft's contribution was never accepted into mainline. It went into the linux-next tree, where low quality / experimental drivers go to be fixed (or dropped).

So what are you doing to fix the problem? Are you volunteering to fix the HV drivers?

I'm sorry, if someone like Greg (who is one of the most talented kernel devs around) can't get the HV drivers to a maintainable state, it's very unlikely that you can.

I don't know if he expected Microsoft to pick up the development. I think he just wanted some guidence from Microsoft. The man works for Novell. He didn't get any.

There is no perfect approach to kernel development. Let's look at your two ideas:

Accept all code into the main tree

Can you accept almost anything in the main tree? You have to draw the line somewhere. Otherwise you'll have people submitting code in brianf*ck. Then again, some C codebases are hard to tell from brainf*ck. But seriously, if some vendor submits some kernel code there is no promise they will continue to maintain it as we see in this example. That's why it has to be in a form where any random kernel dev will be able to get around the driver.

Have a stable binary interface

This is easier said then done, especially in kernel space. How do you evolve the kernel under a stable API? Often you can not do this without changing the API. So you have to maintain multiple subsystems, with different drivers using inferior subsystems. You also have to add additional code to mediate control between all these subsystems, two subsystems can't both access a USB bus at the same time. That makes the kernel more complex to maintain, since you have multiple subsystems doing the same thing, and subsystems who only purpose is manage other redudant subsystems. Of course, if you want to get rid of one you might wreck all the drivers that use that subsystem, this only becomes more difficult as time goes on. Even Windows with all it's development manpower doesn't have a fully stable binary inferace. Try using GINA drivers in Vista.

True. But the original developer(s) aren't necessarily "any random kernel dev", so you have to accept that they may no longer be able to "get around the driver" once you've butchered it to fit your styling. If you take that approach, it has to be the kernel teams responsibilty to continue to maintain every aspect of the driver. Tough luck on the kernel team if that turns out to be hard work; that's the price you pay for taking the easy route within the kernel - driver development becomes a major burden.

Well seriously if you are going make a Linux driver it's in your best interest to hire someone who knows Linux kernel development and can code C that fits the Linux manual of style. That's what the major hardware vendors do.

Indeed. Developing operating system kernels is hard. Just like writing hardware drivers is hard. And no, you can't guarantee that a point won't arise that you have to break compatibility with older drivers to sustain development. This results in lots of long term planning and a carefully roadmapped design of APIs to provide long term stability for driver writers for as long as possible, with a long and careful transition period between APIs. It's a more sustainable solution, however, since it balances the workload between the kernel team and the individual driver writers.

Unfortunately Linux doesn't have the kind of manpower where it can maintain redundant subsystems.

You have to figure that really what works for Windows doesn't mean it will work for Linux. Windows is development by a company, Linux is developed by a consortium of dozens of companies, individuals, non-profits and governments. In Linux there is no distinction between a driver writer and a kernel developer. If a driver exposes some feature that is not part of the subsystem, he adds it into that subsystem. A driver isn't this well enclosed piece of code. It's very tree like in general, drivers share a lot of code.

Linux needs a concise design because it needs to fit into devices with limited resources like routers, and still be able to power the big iron and supercomputers. There is literally millions of different build targets in a vanilla kernel that mutate it to handle all kinds of tasks. Windows NT doesn't have those requirements.

But an enormous chunk of that code is going to be the same between the Windows and Linux (and Mac) versions. Why should driver developers waste their time maintaining an entirely seperate code base just because, style-wise, the Linux kernel developers don't like it? How is that even remotely cost effective?

So write all your platform drivers in the Linux style. There are many many hardware OEMs that somehow manage this. I don't feel this is a real issue, and the kernel would be a big mess if they did it any other way.

As they do on Windows (see miniport drivers), the difference is that the design has developed such that modularity can exist without random bits of new source being scattered all over the kernel. It's ironic (given what a mess the Win32 layering was around the XP timeframe) that Windows is becoming better at modular development precisely because it's closed source, wheras Linux is rapidly heading in the direction of becoming an overly complicated bloaty mess.

I don't really agree. Anyway the whole existance of the MinWin project leads me to believe that Windows is not quite as modular as we are led to believe. Unfortunately there is no reliable way to settle this: Windows is closed source. The most you can go by is what Microsoft allows the general public to know in the literature they publish.

But then maybe it's time to see that "one size fits all" just isn't going to cut it. Maybe it's time to split the project. Or to give up on the bits that just clearly aren't ever going to be a Linux strong point, like the desktop.

I think it works just fine actually. Linux is not "one size fits all", despite being a monolithic design. Because of it's open source nature, Linux has micro-kernel and monolithic advantages. The advanced build system with many possible build targets allows you to roll a kernel that is vastly different from another in the same source tree. So Linux benefits from a really good source (or compile-time) modularity, and thus avoids many of the disadvantages of runtime modularity while sharing in many of it's advantages.

The concept of the source code as configuration mode is pretty foreign in a closed source system, so it's a unique advantage that only open source can really deliver. It would be cool to see desktop distros take advantage of this more often ("bake" a optimized kernel for the computer during the install process).

The last part is your opinion and it is one I strongly disagree with. But ultimately I respect it. Linux as a desktop is not for everyone.