Так что же, ядро многослойное, модульное, или какое?

Все методы минимизации сложности основываются на одном принципе: разделяй и властвуй. Таким образом, все они являются вариациями на тему разбиения большой и сложной в решении проблемы (или системы) на некоторое количество менее сложных подпроблем (или подсистем) до тех пор, пока результаты разбиения не станут столь просты, что их можно будет решить.

Рассмотрим три классических метода построения больших систем, принятые в компьютерной инженерии:

• Слои (уровни). Декомпозиция решения на такие части, каждая из которых решает более низкий уровень проблемы, служит основой для более высокого уровня и способна работать на более высоком уровне абстракции. Наиболее известными и удачными примерами многослойного (многоуровневого) проектирования программного обеспечения следует считать OSI и стек протоколов TCP/IP. Подход с разбиением на слои к проектированию ОС может включать уровень, напрямую взаимодействующий с аппаратными средствами, и уровень абстракции аппаратных средств; в результате более высокие уровни могут взаимодействовать с дисковыми устройствами, сетевыми картами и т.п. без необходимости учета деталей функционирования каждого устройства.

  Одна из характеристик, связанных с многослойным проектированием, заключается в том, что в процессе проектирования строится словарь со все увеличивающейся степенью детализации по мере поднятия на более высокие слои. Еще одна характеристика состоит в том, что можно прозрачно передать информацию с одного слоя на слои, находящиеся выше или ниже. В лучшем случае перенос многослойной ОС на другую платформу потребует переписывания только одного самого нижнего слоя. Чистая многослойная реализация может оказаться медленной, поскольку верхние слои должны выполнять свою работу непрямо, но через последовательность слоев, находящихся ниже, т.е. слой N взаимодействует со слоем N–1, который, в свою очередь, взаимодействует со слоем N–2, и т.д. до тех пор, пока не выполнится реальная работа на слое 0. Естественно, что результаты должны подняться по слоям до того слоя, на котором они необходимы. Следовательно, многие системы такого рода имеют возможности непосредственного взаимодействия между несмежными слоями, что увеличивает их быстродействие, но усложняет передачу информации, поскольку теперь от одного слоя, на который передается информация, могут зависеть несколько слоев, расположенных выше.

• Модули. Модуль скрывает некоторую хорошо определенную порцию функциональности за абстрактным интерфейсом. Одно из основных предназначений модулей — отделять интерфейс от реализации, что дает возможность изменять реализацию одного модуля без влияния на остальные модули, которые с ним взаимодействуют через его интерфейс. Контекст модуля отражает концептуальные границы определенного аспекта области решений. Чистой модульная ОС может иметь модуль для дисковой подсистемы, модуль для подсистемы управления памятью и т.д. Основное отличие чистой модульной от чистой многослойной системы заключается в том, что отдельный модуль может свободно использоваться любым другим модулем — здесь не существует понятия модуля, находящегося «выше» или «ниже». (В этом смысле модули являются обобщением слоев — слой подобен модулю, который может использоваться, как максимум, одним модулем, находящимся непосредственно над ним.)

• Объекты. Объекты отличаются от модулей, поскольку, во-первых, заключают в себе другой способ мышления и могут иметь независимое поведение. Однако для наших целей достаточно представлять объект как нечто, ненамного большее, чем структурированный способ использования модуля. Компоненты, очередное усовершенствование идеи объектов, ничего выдающегося в проектирование ОС пока еще не внесли. С нашей точки зрения они не настолько сильно отличаются от модулей, чтобы выносить их в отдельную категорию.

Рис. 3.1 демонстрирует ядро с точки зрения многослойного подхода, где заметны слой, зависящий от архитектуры, и над ним — слой, от архитектуры не зависящий. (Строго говоря, должен существовать еще один архитектурно-зависимый слой на верхушке, поскольку интерфейс системных вызовов находится между приложениями и ядром, а он-то как раз зависит от архитектуры.) В свою очередь, на рис. 3.2 продемонстрирован модульный подход к ядру.

Если рассуждать с точки зрения правильности, то оба представления совершенно правильны. Либо же оба неверны. Я мог бы целыми днями рисовать рисунки, пытаясь убедить кого-то, что ядро следует тем, а не иным правилам; это было бы возможно потому, что в ядре заложено множество идей. Истина, однако, состоит в том, что ядро Linux ни строго многослойное, ни строго модульное, однако строго прагматично. (Действительно, если и существует одно слово, которым можно охарактеризовать всю систему Linux от проектирования до реализации, то это слово «прагматизм».) Возможно, наиболее безопасной точкой зрения будет считать реализацию ядра модульной, хотя иногда модули преднамеренно пересекают границы модулей во имя достижения большего быстродействия.

Таким образом, процесс проектирования Linux отражает и теорию, и прагматизм. Linux вовсе не игнорирует методологии проектирования; в философии, положенной в основу проектирования Linux, методологии проектирования подобны компиляторам — инструментам для выполнения определенной работы. Выбор того или иного принципа проектирования (например, объектов) и всеобъемлющее, без каких бы то ни было исключений, его применение может послужить хорошим способом проверки границ применимости принципа или источником для построения обучающей системы для конкретной методологии. Однако это ошибочный путь построения ядра, которое бы удовлетворяло целям проектирования Linux, к тому же цели проектирования Linux не содержат в себе ничего «чистого». На пути достижения этих целей разработчики Linux, как правило, нарушаю принципы проектирования.

Действительно, что правильно для Linux, то правильно и для многих успешно завершенных систем. Большинство широко используемых, не «игрушечных» систем по сути своей прагматичны. Некоторые разработчики пытаются отыскать некую волшебную палочку, принципы проектирования или методологию, которые служили бы лекарством от всех бед. И вдруг они оказываются между молотом и наковальней. Успешно завершенные проекты, среди которых и ядро Linux, в общем случае зиждятся на применении множества методологий для различных частей системы или на различных уровнях описания. Результат может не быть чистым и понятным, однако полученный гибрид оказывается устойчивей и качественней эквивалентов, создаваемых в рамках чистых методологий.