Pull to refresh

Microsoft хочет внести свой код в ядро Linux — давайте разберёмся

Configuring Linux *
В этой статье я хочу развеять всеобщее помешательство насчёт того, что Microsoft хочет внести свой код в ядро Linux. Для начала давайте посмотрим, что это за код. В пресс-релизе [1] Microsoft как всегда лукавит, заявляя, что это код драйвера, написанный для сообщества Linux: Microsoft Contributes Linux Drivers to Linux Community — название пресс-релиза. Формально это так, но на самом же деле, в ядро вносится «система поддержки штанов» для улучшения производительности при работе Linux внутри Microsoft-освской виртуальной машины Hyper-V. Для сравнения, другие виртуальные машины (VMware и VirtualBox) тоже имеют свои модули ядра и инструменты, устанавливаемые в гостевую ОС. Однако VMware и Sun поддерживают их самостоятельно, в vanilla ядро этот код не входит.

Тем не менее, виртуальные машины от VMware и Sun вполне могут полноценно запускать Linux в качестве гостевой ОС даже если гостевые инструменты не установлены (работает сеть, X сервер прямо после установки гостевой ОС). Учитывая критическую концентрацию евангелистов от MS на хабре, хочу у них спросить: а в Hyper-V если не собирать драйвер для гостевой ОС сеть работать будет?

Зачем же Microsoft вносить свой код в ядро? Ведь out-of-tree модули для поддержки виртуальных машин имеют большое преимущество: код таких модулей распространяется вместе с соответствующей версией виртуальной машины и таким образом может включать поддержку всех новых функций этой версии ВМ. А если код включён в ядро, виртуальной машине придётся работать с той версией кода, которая включена в конкретную версию ядра гостевой ОС. Это вполне может сильно усложнить код ВМ, если протокол обмена данными будет меняться или расширяться в будущем. Или решение будет в стиле Microsoft: ограничить круг «пригодных» для запуска ядер на данной версии ВМ ядрами, выпущенными после ВМ (и, соответственно, включающими поддержку функций новой ВМ).

Здесь [2] можно найти сам код, предлагаемый для включения в ядро. В код Microsoft принесла все лучшие традиции WinAPI:
  • все typedef'ы BYTE, LONG, ULONG, ULONG_PTR, DWORD, и другие друзья
    WinAPI'шника на месте. HANDLE на месте. Я вам даже больше скажу — в их коде даже NULL определён! (Если кто не знает, то в ядре Linux есть все необходимые typedef'ы и #define'ы аналогичного назначения)
  • "#ifdef __cplusplus" (напомню, что C++ в ядре Linux отродясь не было)
  • тип «NTSTATUS» вместе с «STATUS_SUCCESS» и «STATUS_FAILURE»
  • сомнительные трюки с упаковкой структур "#pragma pack(push,1)", "__attribute__((packed))"
  • "#pragma once"
  • List.h — собственный велосипед для работы с двусвязным списком (в Linux есть linux/list.h с аналогичными возможностями)
  • InterlockedIncrement, BitTestAndSet, Sleep и прочие обёртки стандартных функций для того, чтобы писать код для ядра Linux как для ядра Windows
  • "#if defined(KERNEL_2_6_5)" и прочие проверки версий ядра (но код-то предназначен для включения в новое ядро!)


Кроме того, игнорирование правил Linux kernel coding style: код написан в том стиле, в котором написано ядро NT. Хотя отступы сделаны табуляцией, во многих местах кода явно видно, что «TAB = 4 пробела» по мнению авторов. Присутствуют строки кода длиной 300+ символов. Используется CamelCase. Комментарии оформлены не так (причём в коде присутствует несколько разных стилей). В некоторых местах наблюдаются поползновения в сторону венгерской нотации (когда в имя переменной префиксом добавляют тип, PFN_ON_OPEN — pointer to function ...).

Для сравнения предлагаю посмотреть два недавних пачта для поддержки HTC Dream: lkml.org/lkml/2009/6/29/163 и lkml.org/lkml/2009/6/29/148 Про оба патча пишут, что нужен cleanup кода. Тем не менее, если посмотреть непосредственно на сам патч, то видно, что стиль кода везде соответствует требуемому Linux kernel coding style и явных велосипедов (типа своих связных списков) нет. Тем не менее, этот код тоже написан сторонней компанией со своими наработками в области software (в коде стоят копирайты Google), но они со своим уставом в ядро Linux не лезут.

Конечно, прежде чем явные недостатки кода не будут устранены, код не попадёт даже в staging в дереве Линуса. Но, на это устранение ошибок тратит силы уже не только Microsoft, но и сообщество. Возникает вопрос, почему и, главное, зачем? Ведь можно элементарно найти пример, когда сырой драйвер не включали в ядро и отправляли разработчика шлифовать код до блеска и соответствия CodingStyle).

Даже когда (если?) код от Microsoft будет натёрт до блеска, и даже покинет staging и будет включён в основное дерево драйверов, на этом проблемы разработчиков ядра не закончатся, а только начнутся. Теперь, по правилам разработки ядра, если кто-то меняет интерфейс какой-то подсистемы ядра (например, SCSI), то он обязан обеспечить работоспособность всех драйверов, использующих эту подсистему, в том числе и драйвер для ВМ Hyper-V. Microsoft получает бесплатные человеко-часы для поддержки своего драйвера в современном состоянии. Profit!

Для справки: VMware поддерживает свои VMware guest tools самостоятельно более 6 лет, при этом в VMware guest tools входят и модуль ядра, и несколько приложений.

[1] www.microsoft.com/presspass/features/2009/Jul09/07-20LinuxQA.mspx
[2] www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-staging
Tags:
Hubs:
Total votes 161: ↑141 and ↓20 +121
Views 4K
Comments Comments 169