LXF81:Интервью

Материал из Linuxformat.

ЯДЕРНЫЙ полковник

Визитка LXF
Грег Кроа-Хартман
Ведущий разработчик ядра с большим опытом написания кодов для всевозможных драйверов, не скрывающий свои взгляды на драйвера с закрытым кодом и на OSDL. Сейчас работает программистом ядра в Novell.
ВОЗРАСТ	36
НАЦИОНАЛЬНОСТЬ	Американец
ИСПОЛЬЗУЕТ LINUX	10 лет
ЯЗЫКИ ПРОГРАММИРОВАНИЯ	7
КОЛИЧЕСТВО ПК	12
ДНЕВНАЯ НОРМА КОФЕ	0 чашек
ПАР САНДАЛИЙ	0
ПРЯМАЯ РЕЧЬ «Наши драйвера работают на всех процессорах. И это действительно показатель мощности.»

Кто двигает разработку драйверов для Linux? Знакомьтесь – Грег Кроа-Хартман, чемпион ядра, главный человек devfs, питающий неизъяснимую любовь к подсистемам PCI Hotplug.

Грег Кроа-Хартман [Greg Kroah-Hartman] – из редкой породы: ему действительно нравится разрабатывать драйвера устройств. Он еще и автор многих из них, а заодно и основных подсистем, с которыми они связаны. USB, PCI, I2C и виртуальная файловая система sysfs – все это участки сферы влияния Грега. Большей частью прозрачной функциональности драйверов, воспринимаемой в ядре Linux как нечто само собой разумеющееся, мы обязаны Грегу, разработавшему немало таких технологий, и он охотно срывает покров тайны с разработки ядра и драйверов. Во введении к книге «Linux Device Drivers» (издательство O’Reilly) он написал: «Разработка драйверов вовсе не является ужасной и запретной территорией», и он делает все возможное, чтобы привлечь новых разработчиков во внутреннее святилище разработки Linux. Быть может, вы станете его новообращенным?

Linux Format: Вместе с Крисом Райтом [Chris Wright], вы – первопроходец разработки третьей ветви ядра Linux 2.6.x.y, где имеется главное древо (super tree), нестабильное древо (unstable tree), и – ваше. А кому вообще нужен этот дополнительный уровень, если нам и без него неплохо жилось?

Грег Кроа-Хартман (ГКХ): Ну, как выясняется, многие пользуются ядрами с http://www.kernel.org, и доверяют им, а не своим дистрибутивам. Мы хотели бы упростить для них процесс исправления ошибок, и чтобы у наших тестеров были исправления ошибок. Обновление безопасности [security updates] – большая проблема: когда у нас появляется заплатка, далеко не все хотят ее получить, предпочитая загрузить полностью новое ядро и работать дальше. Это большая уступка, и мы знаем, что должны на нее пойти. У нас есть набор правил, и эти правила кажутся хорошими и строгими. До сих пор они работали – переходя на личности, команда, в которой работаем мы с Крисом, сработала действительно хорошо – спросите Криса. Похоже, что пользователям это нравится. И дистрибьюторам это тоже нравится – они могут базировать на этом свое ядро, и им не надо возиться с мелкими заплаточками. Например, ваше ядро основано на 2.6.11-4…

LXF: Я перешел на ядро с inotify Роберта Лава (Robert Love). Так вот почему оно такое стабильное! И что, ядро постоянно таким будет?

ГКХ: Настолько, насколько что-либо вообще может быть постоянным: сейчас оно работает, а если перестанет, то мы… изменимся. Это же не навечно изваяно в камне. Надо приспосабливаться.

LXF: Вы упомянули, что другие ОС используют драйвера для Linux. Syllable, IBM K42…

ГКХ: Hurd…

LXF: Да, и Hurd! Вы считаете, что это – в духе идеалов открытого кода, или, повашему, в дальней перспективе это плохо?

ГКХ: Нет, меня удивляет, что мы не делимся всем и полностью. Парни из IBM K42 не хотят писать драйверов – они горят желанием работать над тем, чем они там занимаются в экспериментальном ядре. Я не очень-то знаю, что они там делают, но им надо, чтобы их машины работали, поэтому им нужен драйвер. А драйвера писать никто не любит. Некоторые любят, но большинство – те, которые занимаются исследованиями – не любит, и все-таки тоже хотят работать, не заботясь о драйверах.

LXF: Не потому ли никто не любит писать драйвера, что это сложно? Сложно отлаживать?

ГКХ: Не думаю. Мне это нравится, вот в чем дело. Это не похоже ни на что другое; традиционно драйверы привыкли считать чем-то низкопробным, скверным, что спихивают на пришедших в фирму новичков. Однако ядро состоит из трех компонентов: оно работает с памятью, с I/O, а затем доходит до оборудования – вот вам и драйвера, они нужны всем: чтобы клавиатура заработала, без драйвера не обойтись. Они очень важны, но писали их традиционно в последнюю очередь. Обнадеживает то, что за долгие годы Линус собрал команду неплохих парней, изменивших этот подход, и наши драйвера славятся высокой стабильностью, и все знают, что мы делаем действительно хорошие вещи. Сетевые решения у нас очень, очень хорошие; SCSI тоже очень хорошее; USB вообще отличное – мы поддерживаем большинство новых устройств быстрее любой другой ОС. Поддержку USB 2.0 мы сделали раньше всех. И всякие другие непростые штуки получаем раньше, чем любая другая ОС. Например, Bluetooth.

LXF: Была забавная ситуация в промежутке между Windows XP Service Pack 1 и 2. Вышел SATA, и его поддержали и SUSE, и Fedora, и Mandriva. Все причитали, как сложно устанавливать Linux, но, естественно, пробуя SATA в Windows до выхода SP2, нарывались на полный отказ – на сообщение: «Не найден жесткий диск». Ничего нельзя было сделать – тут и оказалось, что Linux проще Windows – он сам обнаруживает устройства.

ГКХ: Да – а вы вообще-то когда-нибудь пробовали Windows устанавливать?

LXF: Да, вот на этой штуке [тычет в ноутбук]. Это непросто.

ГКХ: Да, мы получаем поддержку оборудования быстрее. Все разработчики устройств используют Linux для выпуска оборудования. IA-64 был создан на Linux, x86-64 был создан на Linux. Парни, занимающиеся оборудованием, любят Linux, они это умеют. У них есть исходный код, и они могут выяснить, что не так с их «железом»… Большую работу выполнили парни из PowerPC: взяли и издали документ, как перевести Linux на гигантские мультипроцессорные PowerPC без firmware и без BIOS. Им не надо было ждать разработчиков BIOS, парни могли сразу приступить к работе с оборудованием. Короче, драйвера важны, и будем надеяться на их стабильность – ведь на стабильность-то все и жалуются. Возможно, драйвера на моей машине отличаются от драйверов на вашей. У меня не такие драйвера, как у вас, потому что что у нас, наверное, разные устройства – вы используете другую мышь.

LXF: Похоже, за недавнее время ядро подверглось множеству изменений в системе защиты. Есть ли у вас сайт по проблемам безопасности, куда можно отсылать свои заплатки или просто комментарии, без широкой публикации?

ГКХ: O, у нас есть список рассылки security@kernel.org.

LXF: И сколько народу занято? Думаю, немного?

ГКХ: Нет, в команде, занимающейся аспектом безoпасности, человек пять. Это частная информация, но, взглянув на их правила, вы поймете, что частной она остается недолго. Действует это так: «Вы присылаете информацию о проблеме, мы изучаем ее, исправляем как можно быстрее, и публикуем». И это новинка, потому что есть группа людей, которая называется vendor-sec, список рассылки для всех самых разных дистрибутивов и множества людей, координирующих обновления системы безопасности. Red Hat, SUSE, Mandriva – все получают обновление системы безопасности в тот же день, так что традиционно у них эта проблема решена. Раньше мы именно так решали проблему безопасности ядра – а сейчас мы упростили это. Если вы нашли уязвимость в ядре – приходите сюда, людям проще сообщать о безопасности. У всех прочих проектов, Mozilla, Apache, есть списки рассылки по безопасности.

LXF: Так сколько все-таки человек в списке рассылки?

ГКХ: По безопасности? Пять или шесть.

LXF: Так… Вы, Линус Торвальдс, Эндрю, Алан Кокс…

ГКХ: Еще Крис Райт за это отвечает.

LXF: Это уже пять!

ГКХ: Может быть, их шестеро. Я не знаю, список очень короткий.

LXF: А Марк Кокс, ответственный за безопасность в Red Hat, тоже в списке?

ГКХ: Нет, это не для дистрибьюторов. Если появится проблема, они об этом узнают.

LXF: Вы сказали на Kernel Summit 2004, что затронули треть ядра. Я выяснял – 1,2 миллиона строк написано и 850000 удалено, просто невероятно. Похоже на колоссальное переписывание.

ГКХ: Эти числа надо брать с щепоткой соли. Они – механические. Бывает, что добавляются и замещаются в точности те же строки – в основном, конечно, нет… Добавляются новые драйвера, пересматривается API ядра, происходят улучшения.

LXF: И долго это делалось?

ГКХ: Восемь месяцев.

LXF: Восемь месяцев? На 1,2 миллиона строк ядра?

ГКХ: Придется рассказать вам о количестве изменений. Каждая индивидуальная заплатка считалась за единицу, у меня было определенное их количество, попадавшее в каждый новый релиз ядра, и это количество росло и росло – примерно 3 000 различных изменений. И есть лучший способ рассматривать это с точки зрения логики производимых изменений.

LXF: Журнал изменений [changelog] явно здорово разросся – по-моему, для версии 2.6.10 он стал 1.5 MБ. Громадный объем.

ГКХ: Возможно, мы тогда слишком засиделись между релизами. Мы поняли, что сразу такой объем загружать сложно.

LXF: Мое понимание стабильности – добавление или удаление чего-то не такое радикальное…

ГКХ: Это традиционный взгляд в разработке программ – что все стабилизируется с течением времени, и менять становится нечего. Но это не то, чем мы занимаемся. Нам надо поддерживать новое оборудование, нам надо добавлять новые свойства, нам надо вносить исправления – и мы постоянно добавляем что-то новое. Посмотрите, что произошло между 2.6.0 и 2.6.8: огромные списки всевозможных добавлений. Мы сделали много нового, и бесспорно, на настоящий момент – это лучшее из ядер, какие у нас были, и всем оно нравится, так что оно того стоило. Нам больше не надо ничего портировать назад. На это затрачено столько времени и энергии у разработчиков ядра. Думаю, мало кто это понимает. И мне совершенно не хочется заниматься этим снова. Версия 2.4 вымотала народ. Сейчас нам не надо этим заниматься: мы счастливы.

LXF: Хотя, справедливости ради, я думаю, надо отметить, что Red Hat и SUSE пять лет – а Red Hat уже и семь лет – будут оказывать поддержку…

ГКХ: Да, верно, они предоставят ядро для уровня предприятия, и в течение N-ного количества лет оно гарантированно не будет меняться, они заявляют, что не собираются ломать API ядра – они гарантируют это – и именно этого хотят их клиенты. Так что это здорово.

LXF: Но кто-нибудь где-нибудь все же будет заниматься обратным портированием в следующие пять лет?

ГКХ: Нет… если вы посмотрите на правила и на их функцию, каждое из них отлично от других. Например, вы не можете добавлять новые функции. Вы не можете поддерживать новое оборудование – режим поддержки будет введен через N-ное число лет, не знаю, что это. Другие операционные системы поддерживают новое оборудование со старыми программами, но это действительно трудно. Но это нужно клиентам, действительно нужно, и поэтому это тоже здорово. А еще нужно постоянно находиться в авангарде, и другие дистрибутивы так и поступают.

LXF: Похоже, что некоторые части Linux не слишком часто меняются. Например, скрипты инициализации [init scripts], возможно, самая медленная часть загрузки. Такие проекты, как InitNG, их распараллеливают, чтобы сделать намного быстрее. Но сейчас-то они тормозят.

ГКХ: Не согласен. Инициализация делает сложные вещи. Fedora заявила: «Давайте ускорим время загрузки, как бы нам построить графики?» и у них есть графики загрузки, они могут показать, на что уходит время и где нужна оптимизация. В Gentoo совершенно заново переписали скрипты инициализации, распараллелили и учли их последовательность, раньше они были написаны по-другому. Парни из Red Hat и SUSE что-то делают, используя D-BUS, у них все подчинено событиям. Инициализация меняется, а быстрой загрузки хочется всем.

LXF: Devfs в версии 2.6.13 был отключен. Уж не прелюдия ли это к его полному удалению?

ГКХ: Верно. Знаете, я начал работать над драйверной моделью ядра года три-четыре назад с Пэтом Мочелом [Pat Mochel]. Он хотел обеспечить нормальную работу управления питанием, я хотел, чтобы работали динамические устройства и постоянное присвоение имен [persistent naming], потому что devfs не умеет этого. [Если] вы присоединяете два USB-принтера, отключаете питание, потом снова включаете, и они могут появиться не в той последовательности. Вы будете вместо черно-белого печатать на цветном – и это не здорово. Нужно постоянное присваивание имен, а в Linux его не было, devfs его не обеспечивал. Поэтому я создал такую драйверную модель для файловой системы, как udev, чтобы обеспечить постоянное присвоение имен. Теперь, когда у нас есть udev, все дистрибутивы включают его, и все им пользуются, и devfs нам не нужен. У меня есть серия заплаток, которые его убирают. Это примерно 8000 строк кода, которые надо удалить из ядра. Когда-то это была крутая вещь – она подсказывала, что нужно делать, но у нее были неизлечимые проблемы. Я говорил с BSD, у них тоже есть проблемы.

LXF: Они тоже его выкидывают?

ГКХ: Нет, они им вполне довольны. У них есть проблемы, но их devfs им нравится. Наш написан по-другому. За ним никогда нормально не следили. Тот, кто за ним присматривал, пропал на три года, а код, за которым никто не следит, начинает распадаться.

LXF: Вы очень тверды насчет бинарных драйверов. Не могли бы вы объяснить, почему бинарные драйвера – скажем, драйвер Nvidia – незаконны?

ГКХ: Сам по себе драйвер Nvidia не является противозаконным. Это очень просто, поговорите с юристом. Я не юрист. GPL дает четкое определение компоновке.

LXF: Смешение кода GPL с кодом не-GPL?

ГКХ: Да, когда они компонуются – потому что это необходимо сделать при загрузке модуля – когда вы связываете код с ядром, вы получаете единый образ, который подпадает под GPL. И это не нейтральная территория.

LXF: И это незаконно?

ГКХ: Это незаконно. Раньше Линус предусматривал правила, например, если вы пишете код на другой операционной системе, мы это разрешаем. Это было вроде исключения и никогда толком не кодифицировалось. А пару лет назад Линус взял и заявил, что больше это правило не работает.

LXF: И как же драйвера это обходят?

ГКХ: Ну, если никто тебя не видит, можно и что-нибудь незаконное провернуть.

LXF: Да, но вы сказали, что драйвер Nvidia не незаконный.

ГКХ: Потому что в нем ничего незаконного. Вы сами, как пользователь, все компилируете и компонуете. И не можете передать этот скомпилированный объект еще комуто, не нарушив GPL.

LXF: И всех таких пользователей Linux ждут судебные процессы …

ГКХ: Но не Nvidia. Они не единственные: многие так делают.

LXF: Что Вы думаете о Ndiswrapper?

ГКХ: Ndiswrapper – грандиозное хакерство. С точки зрения закона, вы опять-таки соединяете две части кода, получается неправильная лицензия. Но это грандиозное хакерство, и я изумлен, что он работает. С технической стороны, я им восхищаюсь.

LXF: Он не облегчил вам жизнь?

ГКХ: Нет, нисколько не облегчил. Бинарные драйвера превращают нашу жизнь в ад. Пользователи сообщают нам о своих проблемах с ядром, и если у них там стоит бинарный драйвер, мы не можем узнать, в чем дело – возможно, он записал что-то где-то поверх ядра и из-за этого – бах! [сломалось], или что-то плохое случилось, а нам этого не понять. Ну и если вы сломали ядро, мы сообщаем: у вас бинарный драйвер, мы не можем оказать вам поддержку… решайте вашу проблему сами. Люди знают: из сообщения об отказе ядра должно быть ясно, что они не работают с бинарными драйверами, иначе никакой поддержки им не будет.

LXF: Вам нужно нечто вроде контрольной суммы [checksum] – но с открытым кодом такой прием безопасности не сработает.

ГКХ: Нет, и мне этого не надо. Ведь дело не в том, чтобы вы ничего такого не делали, а в том, чтобы мы знали, что не сможем оказать вам поддержку.

LXF: Помимо подписи «signed off by», повашему, как судебное разбирательство SCO влияет на разработку – если влияет?

ГКХ: Возможно, оно влияет на то, как люди воспринимают Linux и используют его, и на предприятиях, и встроенным, и где бы то ни было, но что касается разработок, нас это никак не остановило. В нескольких судебных разбирательствах упоминались наши имена, и нам пришлось общаться с кучей юристов, вот и все.

LXF: И даже пары недель не ушло на сомнения, не надо ли быстренько переворошить исходный код?

ГКХ: Нет. Linux – лучше всех документированная крупная кодовая база. Там всегда точно известно, откуда что взялось. Всегда можно проследить историю всех этих публичных изменений, до самого истока. Не бывает такого, чтобы мы не знали, откуда что взялось, мы всегда это знаем, это же происходит открыто. Можно по-другому повернуть вопрос: вот эти закрытые операционные системы, откуда они берут свой код? Почем мы знаем, что они не взяли наш? Я не говорю, что они это сделали, но вы ж понимаете. А за наши программы я нисколько не боюсь.