Microsoft wants to bring its code into the Linux kernel - let's see
In this article, I want to dispel the general madness that Microsoft wants to bring its code into the Linux kernel. First, let's see what this code is. In the press release [1], Microsoft, as always, is cunning, stating that this is driver code written for the Linux community: Microsoft Contributes Linux Drivers to Linux Community is the name of the press release. Formally, this is the case, but in fact, the “pants support system” is introduced into the kernel to improve Linux performance inside the Microsoft-Ovsky Hyper-V virtual machine. For comparison, other virtual machines (VMware and VirtualBox) also have their own kernel modules and tools installed in the guest OS. However, VMware and Sun support them independently, this code is not included in the vanilla kernel.
However, VMware and Sun virtual machines can fully run Linux as a guest OS even if the guest tools are not installed (the network is working, the X server is right after the guest OS is installed). Given the critical concentration of evangelicals from MS on Habré, I want to ask them: in Hyper-V, if you don’t collect a driver for a guest OS, will the network work?
Why should Microsoft contribute its code to the kernel? After all, out-of-tree modules for supporting virtual machines have a great advantage: the code of such modules is distributed along with the corresponding version of the virtual machine and thus may include support for all new features of this version of VM. And if the code is included in the kernel, the virtual machine will have to work with the version of the code that is included in the specific kernel version of the guest OS. This may well complicate the VM code if the data exchange protocol changes or expands in the future. Or the solution will be in the style of Microsoft: limit the range of "suitable" for launching kernels on this VM version by the kernels released after VM (and, accordingly, including support for the new VM functions).
')
Here [2] you can find the code itself proposed for inclusion in the kernel. In the code Microsoft brought all the best traditions of WinAPI:
In addition, ignoring the rules of Linux kernel coding style: the code is written in the style in which the NT kernel is written. Although indents are tabbed, in many places of the code it is clearly visible that “TAB = 4 spaces” according to the authors. There are lines of code with a length of 300+ characters. CamelCase is used. Comments are not decorated (and in the code there are several different styles). In some places there are stumps towards the Hungarian notation (when type is added with a prefix to the variable name, PFN_ON_OPEN - pointer to function ...).
For comparison, I suggest to look at two recent patch for HTC Dream support: lkml.org/lkml/2009/6/29/163 and lkml.org/lkml/2009/6/29/148 Both patches write that cleanup code is needed. However, if you look directly at the patch itself, you can see that the style of the code always corresponds to the required Linux kernel coding style and there are no explicit bikes (such as its linked lists). Nevertheless, this code is also written by a third-party company with its own developments in the field of software (Google's copyright code is in the code), but they do not climb into the Linux kernel with their charter.
Of course, before the obvious shortcomings of the code are eliminated, the code will not fall even into staging in the Linus tree. But, not only Microsoft, but also the community, is wasting energy on eliminating errors. The question arises, why and, most importantly, why? After all, you can easily find an example when the raw driver was not included in the kernel and sent the developer to polish the code to shine and match CodingStyle).
Even when (if?) Microsoft's code is rubbed to shine, and even leaves staging and is included in the main driver tree, this will not end the problems of kernel developers, but will only begin. Now, according to the rules of kernel development, if someone changes the interface of some kernel subsystem (for example, SCSI), then he must ensure the operability of all drivers using this subsystem, including the driver for the Hyper-V VM. Microsoft gets free man-hours to keep its driver up-to-date. Profit!
For reference: VMware has been maintaining its own VMware guest tools for more than 6 years, while VMware guest tools include a kernel module and several applications.
[1] www.microsoft.com/presspass/features/2009/Jul09/07-20LinuxQA.mspx
[2] www.kernel.org/pub/linux/kernel/people/gregkh/.6-2/gregkh-05-staging
However, VMware and Sun virtual machines can fully run Linux as a guest OS even if the guest tools are not installed (the network is working, the X server is right after the guest OS is installed). Given the critical concentration of evangelicals from MS on Habré, I want to ask them: in Hyper-V, if you don’t collect a driver for a guest OS, will the network work?
Why should Microsoft contribute its code to the kernel? After all, out-of-tree modules for supporting virtual machines have a great advantage: the code of such modules is distributed along with the corresponding version of the virtual machine and thus may include support for all new features of this version of VM. And if the code is included in the kernel, the virtual machine will have to work with the version of the code that is included in the specific kernel version of the guest OS. This may well complicate the VM code if the data exchange protocol changes or expands in the future. Or the solution will be in the style of Microsoft: limit the range of "suitable" for launching kernels on this VM version by the kernels released after VM (and, accordingly, including support for the new VM functions).
')
Here [2] you can find the code itself proposed for inclusion in the kernel. In the code Microsoft brought all the best traditions of WinAPI:
- all typedefs BYTE, LONG, ULONG, ULONG_PTR, DWORD, and other friends
WinAPI's on the spot. HANDLE in place. I'll even tell you more - in their code even NULL is defined! (If anyone does not know, then the Linux kernel has all the necessary typedefs and # defines of a similar purpose) - "#ifdef __cplusplus" (recall that there was no C ++ in the Linux kernel)
- type "NTSTATUS" together with "STATUS_SUCCESS" and "STATUS_FAILURE"
- doubtful tricks with the packaging of structures "#pragma pack (push, 1)", "__attribute __ ((packed))"
- "#pragma once"
- List.h - own bike for working with a doubly linked list (Linux has linux / list.h with similar capabilities)
- InterlockedIncrement, BitTestAndSet, Sleep and other standard function wrappers to write code for the Linux kernel as for the Windows kernel
- "#if defined (KERNEL_2_6_5)" and other checks of kernel versions (but the code is intended to be included in the new kernel!)
In addition, ignoring the rules of Linux kernel coding style: the code is written in the style in which the NT kernel is written. Although indents are tabbed, in many places of the code it is clearly visible that “TAB = 4 spaces” according to the authors. There are lines of code with a length of 300+ characters. CamelCase is used. Comments are not decorated (and in the code there are several different styles). In some places there are stumps towards the Hungarian notation (when type is added with a prefix to the variable name, PFN_ON_OPEN - pointer to function ...).
For comparison, I suggest to look at two recent patch for HTC Dream support: lkml.org/lkml/2009/6/29/163 and lkml.org/lkml/2009/6/29/148 Both patches write that cleanup code is needed. However, if you look directly at the patch itself, you can see that the style of the code always corresponds to the required Linux kernel coding style and there are no explicit bikes (such as its linked lists). Nevertheless, this code is also written by a third-party company with its own developments in the field of software (Google's copyright code is in the code), but they do not climb into the Linux kernel with their charter.
Of course, before the obvious shortcomings of the code are eliminated, the code will not fall even into staging in the Linus tree. But, not only Microsoft, but also the community, is wasting energy on eliminating errors. The question arises, why and, most importantly, why? After all, you can easily find an example when the raw driver was not included in the kernel and sent the developer to polish the code to shine and match CodingStyle).
Even when (if?) Microsoft's code is rubbed to shine, and even leaves staging and is included in the main driver tree, this will not end the problems of kernel developers, but will only begin. Now, according to the rules of kernel development, if someone changes the interface of some kernel subsystem (for example, SCSI), then he must ensure the operability of all drivers using this subsystem, including the driver for the Hyper-V VM. Microsoft gets free man-hours to keep its driver up-to-date. Profit!
For reference: VMware has been maintaining its own VMware guest tools for more than 6 years, while VMware guest tools include a kernel module and several applications.
[1] www.microsoft.com/presspass/features/2009/Jul09/07-20LinuxQA.mspx
[2] www.kernel.org/pub/linux/kernel/people/gregkh/.6-2/gregkh-05-staging
Source: https://habr.com/ru/post/64986/
All Articles