книги хакеры / журнал хакер / 054_Optimized

ИНТЕРВЬЮ С ДЖОНАТАНОМ КОРБЕТОМ

TanaT (TanaT@hotmail.ru)

Полет

íà ÿäðå

Джонатан Корбет (Jonathan Corbet) написал книгу по ядру Linux (сейчас рабо-

тает над ее третьим изданием) и создал Linux Weekly News, исполнительным ре-

дактором которого он сейчас и является. В этом интервью Джонатан раскры-

вает основные концепции ядра UNIX и объясняет свой интерес к этой теме.

Õ: Джонатан, можете объяснить, почему вас привлекает именно ядро операционной системы?

JC: Хороший вопрос. Впервые я серьезно заинтересовался операционными системами в 1980 году (ну, примерно), когда Эва Немес (Evi Nemeth) разрешила мне повозиться с VM-алгоритмом в ранних версиях BSD для VAX 11/780 (Virtual Address eXtension – популярное семейство 32-разрядных миникомпьютеров, выпускавшихся с 1978 по 1990 г.

бывшей корпорацией Digital Equipment Corp. - прим. автора). Программирование на уровне ядра – это своего рода соревнование: вам всегда приходится думать о том, что может произойти в другом месте системы, там, где вы этого не ожидаете. Если программист ядра все сделал правильно, система правильно работает во всех ситуациях. Правда нужно заметить, что низкоуровневый программист не может отвечать за более высокие системные слои. Я всегда интересуюсь тем, что происходит за сценой. К примеру, если я веду своих детей в цирк, то обращаю больше внимания не на представление, а на людей «в черном», которые помогают актерам исполнять свои номера. Та часть жизни, которая скрыта от глаз, наиболее интересна.

Õ: А кто такая Эва Немес?

JC: О, Эва – это человек, хорошо известный в кругу BSD и USENIX сообществ. Она является профессором (в отставке) Колорадского Университета (University of Colorado). Она также соавтор книги «Unix System Administration Handbook» (позднее она была переработана в Linux System Administration Handbook).

Õ: Что такое VM-алгоритм? Очень похоже на виртуальную память.

JC: Да, так и есть. Давным-давно, в 1981 году, 4BSD, использующая виртуальную память, была еще очень молодой системой. Эва испытывала затруднения с большими приложениями. Когда те загружались в память, все остальное приходилось принудительно сбрасывать в swap. Естественно, при этом страдала производительность – система реагировала на события слишком медленно. Не забывайте, что в те времена использовались VAX 11/780. Когда к ним подключалось большое число пользователей, медленная реакция доводила людей до истерики. Я усовершенствовал алгоритм сканирования страниц памяти таким образом, чтобы записывать в swap лишь информацию,

принадлежащую ресурсоемким процессам, а все остальное оставлять в памяти. Это было мальчишеским баловством, и, конечно же, ни у кого не возникло желания послать мой код в Беркли для рассмотрения его экспертами. Однако именно этот опыт положил начало моим исследованиям ядра.

Õ: Опишите, пожалуйста, структуру ядра Linux.

JC: Это довольно сложный вопрос, но я все-таки попытаюсь ответить. Ядро Linux является монолитным, то есть отдельным, большим образом, который содержит в себе все основные системные функции. В этом смысле такое ядро отличается от ядер таких систем, как Mach (которые основаны на небольших ядрах с прохождением сообщений).

Ядро можно разделить на подсистемы: виртуальную память, файловую систему, сетевую поддержку и т.д. Как и большинство ядер, ядро Linux - большая программа, реагирующая на события. Большую часть времени (в идеале) ядро ничего не делает. Оно спокойно посапывает и не мешает пользователю работать со своими приложениями. Как только что-то требует внимания ядра (например, аппаратное прерывание, системный вызов, создающий процесс), ядро реагирует на событие и выполняет требуемые действия. Затем оно снова возвращает контроль приложениям пользователя.

Õ: Вы не могли бы подробнее пояснить суть термина «монолитное ядро»?

JC: Это довольно просто. Монолитное ядро – это больший цельный «кусок». При этом существует всего один исполняемый образ и одна большая непрерывная часть памяти, где данный образ хранится. Все привилегированные операции (доступ к аппаратному обеспечению) проходят через образ ядра. В противоположность монолитным существуют микроядра. Микроядра строятся на минимуме требуемой функциональности: механизме прохождения сообщений и контроле над процессами. Все остальные функции берут на себя привилегированные внешние процессы. Таким образом, поддержка сетей, файловой системы и аппаратных драйверов вынесена из ядра и размещена во внешнем коде.

Õ: В чем на практике проявляется разница между такими подходами к строению ядра?

JC: Микроядра долгое время претендовали на первое место, но судьба решила по-ино- му. Микроядра обещали и производительность, и переносимость, и практическую гибкость. Когда система собирается из маленьких кусочков (составных частей ядра), вы можете многое поменять, модифицировав лишь требуемый кусочек. Когда дело дошло до практики, микроядра не оправдали ожиданий. «Микро»-часть ядра на деле является не такой уж и маленькой, а добиться нормального уровня производительности оказалось не так просто. Высокая скорость легко достигается, если ядру не требуется обрабатывать большое число сообщений и переключать контекст для каждой операции. Те, кто действительно интересуется этой темой, могут просмотреть знаменитый спор между Линусом Торвальдсом и Эндрю Танненбаумом (Linus Torvalds и Andrew Tannenbaum): www.oreilly.com/catalog/opensources/book/appa.html.

Õ: Можете привести примеры операционных систем, построенных на микроядрах?

JC: Windows 2000 построена на микроядре. Пожалуй, больше я и не знаю :). В мире свободного ПО Mach является известной системой на архитектуре микроядра. Это ядро положено в основу Apples OS X, а также используется в проекте GNU HURD.

Õ: Расскажите, пожалуйста, об ошибках и багах, содержащихся в коде ядра.

JC: Огромное количество багов живет в коде годами. И никто их не замечает. Проект Stanford Checker предлагает некоторые средства, позволяющие автоматизировать процесс поиска багов. Хотя большинство багов безобидны, некоторые из них все же могут вызвать серьезные проблемы. Переполнение буфера и тому подобное встречается в

ядре довольно редко. Разработчики ядра очень внимательно относятся к таким вещам и делают все возможные и невозможные проверки, чтобы предотвратить любые переполнения. Настоящие проблемы вызывают баги, связанные с аппаратным обеспечением и параллельной обработкой. Очень сложно поддерживать аппаратное обеспечение, которое только появилось на складах магазинов, но которое вот-вот уже установит себе пользователь. К тому же производители железа не всегда следуют предписанным спецификациям и допускают некоторые отклонения. Основная причина необходимости в огромном числе тестеров в том, что у разработчиков просто не может быть всех возможных видов аппаратного обеспечения. Пользователи же легко наткнутся на проблему, когда какая-то определенная сетевая карта или, к примеру, новый дисковод ведут себя немного по-другому. Но этого хватит, чтобы повесить систему. Параллелизм связан с тем, что в ядре многие события происходят одновременно. Вы можете запрограммировать простое выражение вида:

a = a + 1;

Компьютер же воспримет его в следующем виде:

-считать значение переменной «а»;

-прибавить к нему 1;

-сохранить результат обратно в «а».

Но на практике возможно, что какой-то другой поток ядра изменит значение «а» между первым и третьим шагами. Избежать этой «гонки» (такое название потому, что результат зависит от того, кто первый сохранит свое значение в «а») и есть главная задача программиста ядра.

Õ: Какие виды исключительных ситуаций могут возникнуть при работе ядра?

JC: Ядро Linux имеет два вида исключений, называемых обычно «oops» и «panic». Как и с каждой системой, паника происходит тогда, когда ядро обнаруживает серьезную неисправность. Если система каким-либо образом повредила сама себя, ей требуется немедленно остановиться, пока она не сделает что-нибудь типа уничтожения файловой системы. Везде, где только возможно, Linux пытается детектировать проблему и справиться с ней без остановки всей системы. Например, многие ситуации типа «oops» приводят к завершению процесса, который нормально запустился, но потом зациклил систему. Но бывают ситуации, когда все настолько плохо, что полная паника является наилучшим выходом. Пользователи стабильных версий ядра, конечно же, никогда не видели ни паник, ни «oops». Но в реальном мире они иногда происходят.

Õ: Можете привести больше примеров ситуаций, когда возникают паника или «oops»?

JC: Недавно найденный TF баг (смотрите http://lwn.net/Articles/15903/) служит хорошим примером паники. Процессор пытается передать управление процессу, которого не существует. Это приводит к краху всей системы. В данном случае у системы нет другой альтернативы, кроме как паниковать. Ядро, поставляемое с Red Hat Linux 7.3 (и некоторыми другими дистрибутивами) содержит баг в файловой системе ext3. Эта ошибка приводит к «oops», завершая время от времени некоторые процессы. К тому же этот баг приводит к замедлению всей системы. Хотя данная ошибка уже исправлена (патч есть и в обновлении от Red Hat), этот случай познакомил многих пользователей с ошибками типа «oops».

Õ: Какие функции выполняет ядро Linux?

JC: Ядро делает все то, что не может быть выполнено в пространстве пользователя. Это означает контроль над доступом к ресурсам: ядру, файловой системе, устройствам и т.д. Некоторые задачи, которые могут быть выполнены на более высоком уровне, внесены в ядро для увеличения производительности. Например, сетевое взаимодействие. Иногда пользователи сами добавляют некоторые функции в ядро по той же причине. Например, сетевой сервер TUX (доступен как отдельный пакет) предоставляет сетевые услуги прямо на уровне ядра (с впечатляющей скоростью, надо сказать). Критерием яв-

ИНТЕРВЬЮ С ДЖОНАТАНОМ КОРБЕТОМ

TanaT (TanaT@hotmail.ru)

ляется интерфейс системных вызовов: пользовательский уровень и ядро общаются между собой вызовами типа open() (функция служит для открытия файла и доступа к данным), fork() (основная функция API процессов, используется для создания нового процесса) и т.п.

Õ: То есть ядро контролирует работу файловой системы?

JC: Да. Хотя возможно реализовать файловую систему на более высоком уровне, этого никто не делает. Опять же из соображений производительности. Скорость файловой системы составляет скорость всей системы в целом. Поэтому поддержка файловых систем, которыми пользуются наиболее часто, включена в ядро.

Õ: Считается, что ядро Linux не содержит никаких решений для ускорения работы графических сред. Конечно, оболочек для Linux довольно много. Но сегодня можно выделить сверхпопулярные GNOME и KDE. Почему не включить в ядро Linux поддержку этих графических сред? Для увеличения производительности. Почему третьи лица не выпускают ядра с поддержкой графических оболочек?

JC: Ну, например, ядро 2.5 имеет встроенный слой буфера кадров. Он используется для доступа к видеоустройствам. Хотя не ясно, насколько эффективен данный метод, ведь и Х-сервер предоставляет хороший низкоуровневый доступ к видеоустройствам.

Перенос Х-сервера в ядро увеличил бы его до гигантских размеров. Это также означало бы, что любые ошибки и проблемы безопасности в Х-сервере (это довольно большое приложение само по себе) могут с легкостью положить на лопатки всю систему. К тому же выгоды от такого переноса не очень ясны. Поэтому никто и не хочет так делать. Если говорить о GNOME и KDE, то они являются приложениями более высокого уровня, чем Х-сервер. Поэтому у них еще меньше причин попасть на уровень ядра.

Õ: Возвращаясь к файловой системе: зачем Linux поддерживает несколько разделов? Windows, к примеру, использует один большой NTFS или FAT32 раздел, а Linux минимум два: Linux native и swap. Чем это обусловлено?

JC: Linux может работать и без swap, а Windows может использовать swap. Здесь нет никакого различия. Swap это лишь способ расширить оперативную память. Инсталляция Linux может разбить файловую систему на несколько разделов (а может и не разбивать). Существует несколько причин, почему следует так сделать:

-Если в одном разделе не хватит места, это никак не отразится на остальных;

-Åñëè каким-либо образом один раздел будет поврежден, другие останутся целыми;

-Вы можете использовать разные файловые системы в разных разделах. Например, ext3 для основной файловой системы, XFS для раздела, содержащего огромные науч- ные базы данных.

-И, конечно же, если у вас несколько дисков, то обойтись одним разделом точно не удастся. Хотя есть способы, как это спрятать.

Linux может работать и на одном большом разделе.

Õ: Что вы можете сказать о стабильности файловой системы Linux? Экспериментально установлено, что компьютер с Windows XP + NTFS можно включать/выключать

колько раз подряд (я видел раз 15-20) и при этом не будет никаких ошибок в файловой системе (NTFS). Linux может похвастаться такими же результатами?

JC: Я не могу определить, какая файловая система стабильнее. Я могу лишь сказать, что более чем за 10 лет использования Linux единственная проблема с файловой системой, которая у меня была, случилась, когда я установил нестабильное «горячее» ядро.

Õ: Чем отличаются ядра Linux и BSD систем?

JC: Прошло много времени с тех пор, как я интересовался ядром BSD, так что не уверен, что смогу ответить точно. Корни ядра BSD намного старше и более распространены, чем Linux’а. Реализация TCP/IP в современной BSD сохранила немало общего со своими самыми старыми версиями. Что же до Linux, то он с самого начала был построен по-другому, в частности Linux использует свой собственный сетевой стек. Конечно, системы немало повлияли друг на друга за последние годы. Одна из самых приятных черт свободного ПО это то, что хорошие идеи очень быстро распространяются и внедряются. К примеру, хотя Linux имеет собственную реализацию виртуальной памяти, он позаимствовал немало мудрых решений из VM-кода FreeBSD.

Õ: А вы отвечаете за какую-нибудь конкретную часть ядра?

JC: Нет, я не вхожу в команду, которая поддерживает какую-либо часть ядра и отвечает за нее. У меня никогда не хватало на это времени, хотя было бы интересно попробовать. Я часто выпускаю небольшие патчи для ядра, которые исправляют ту или иную проблему. Мой самый значительный вклад в разработку ядра это второе издание Драйверов Устройств для Linux (Linux Device Drivers) в соавторстве с Алессандро Рубини (Alessandro Rubini). LDD было выпущено под лицензией Free Documentation License.

Õ: В состоянии ли один человек написать ядро? Какие знания для этого требуются?

JC: Ну, Линус доказал, что это возможно. Понимаете, не так уж и сложно написать ядро, которое сможет обрабатывать основные системные вызовы, управлять процессами и устройствами и т.д. А вот создать ядро, которое принесет что-то полезное в этот мир, задача намного более сложная. Ядро Linux не является работой какого-то отдельного разработчика, это результат работы сотен программистов по всему миру. Что касается знаний и навыков, то необходимо владеть языком программирования, обеспечивающим низкоуровневый доступ к внутренностям машины. Именно поэтому ядро Linux написано на С и (небольшая часть) на ассемблере. Много лет назад была идея переписать ядро Linux на С++, но ее забросили. Среди прочих вещей, С++ скрывает некоторые вещи, происходящие в глубине. Это сильно снижает контроль и производительность, что не позволяет выполнять требуемые задачи.

Õ: То есть нужно хорошо разбираться в С и ассемблере, так?

JC: Если вы хотите написать свое собственное ядро, вам, конечно же, понадобится ассемблер для работы с процессором, под который вы программируете. И язык более высокого уровня (например, С). Многие люди, занимающиеся ядром Linux, не особо разбираются в ассемблере, им вполне хватает и С.

Õ: Почему ядро Linux так часто обновляется?

JC: «Выпускайте как можно раньше, обновляйте как можно чаще» - это девиз разработки свободного ПО. Часто выпуская новые версии, Линус позволил другим разработчикам (и пользователям) следить за всем, что происходит и, я надеюсь, отслеживать любые проблемы на самой ранней стадии. На самом деле пользователи Linux обновляют ядро не так уж и часто. Существуют стабильные реализации ядра – они появляются раз в два года. Все остальные обновления направлены лишь на устранение найденных ошибок.

Õ: Есть ли смысл в обновлении своего ядра Linux? Не лучше ли установить какую-ни- будь стабильную версию и оставить свою систему в покое?