Драйверы, встроенные в ядро, и драйверы, реализуемые в виде модулей

🕛 18.06.2009, 16:23

Как вы уже знаете, при настройке ядра можно включить или отключить некоторые свойства ядра, например, вы можете разрешить или запретить использование конкретного Ethernet-адаптера. Существуют опции, значения которых можно выбирать более чем из двух возможных вариантов. В качестве примера рассмотрим опцию Packet Socket. Для этой опции могут быть заданы значения Y, М и N. Значение Y (Yes) указывает на то, что средства, соответствующие данной опции, должны быть включены в основной файл ядра, а значение N (No) запрещает использование этих средств. Значение М задает некоторое "промежуточное" решение. Если вы выберете значение М, то соответствующие средства будут скомпилированы, но не войдут в основной файл ядра. Вместо этого фрагмент кода будет реализован как отдельный модуль ядра, который по мере надобности загружается или удаляется из памяти. Для опций, являющихся подопциями других опций (например, Packet Socket: Mmapped IO, показанной на рис. 1.1), значение М обычно не предусмотрено. Решение о включении их в основной файл ядра или реализации в виде отдельного модуля принимается в зависимости от значения родительской опции.

Средства, включенные в основной файл ядра, доступны с момента загрузки системы и до окончания ее работы. Ситуация, при которой фрагмент кода будет удален из памяти, возникнуть не может. Существуют опции, для которых реализующий их программный код должен быть включен в основной файл ядра. Так, например, файловая система, в которой содержится корневой каталог системы, должна быть доступна с момента загрузки, поэтому соответствующий драйвер должен быть включен непосредственно в ядро. Если вы установили рассмотренную ранее опцию Root File System on NFS, вам придется скомпилировать средства поддержки сетевых устройств и включить их в ядро.

На первый взгляд может показаться, что все средства, которые будут использоваться при работе системы, следует включить в основной файл ядра, однако такой подход имеет серьезный недостаток: при этом увеличивается объем оперативной памяти, занимаемой ядром. Кроме того, размер файла ядра на диске также увеличивается, что может создавать трудности при загрузке системы. Поэтому в системе Linux предусмотрена возможность компилировать средства, соответствующие большей части опций, в виде модулей. Это позволяет работать с ядром небольшого размера и в то же время обеспечивает поддержку большого количества разнообразных устройств. В частности, в виде модулей могут быть скомпилированы средства для работы с большинством сетевых устройств, поэтому драйверы, включаемые в состав дистрибутивных пакетов, обычно подготавливаются именно в таком виде.
Если администрирование компьютера под управлением Linux является вашей обязанностью, то именно вам предстоит решить, следует ли использовать драйверы сетевых карт, реализованные в виде модулей, или их следует включить в состав ядра. Если вы включите драйвер сетевой карты непосредственно в ядро системы, вам не придется обеспечивать при настройке системы, чтобы перед началом сетевого обмена загружался требуемый модуль. (На самом деле система, поставляемая как дистрибутивный пакет, изначально сконфигурирована так, что данная задача решается корректно.) С другой стороны, если вы администрируете большое количество компьютеров, на которых установлена система Linux, то, возможно, предпочтете создать ядро и набор модулей, которые будете устанавливать на различные компьютеры. В этом случае целесообразно реализовать драйверы в виде модулей.

Программные средства поддержки стека протоколов также могут быть непосредственно включены в ядро или скомпилированы как модули. (Исключением являются протоколы TCP/IP; их можно либо включить в основной файл ядра, либо не использовать вовсе; в виде модулей можно реализовать лишь средства, соответствующие некоторым подопциям опции, управляющей использованием данного стека протоколов.) Так, например, если вы знаете, что каталоги в файловых системах других компьютеров, предоставляемые средствами NFS, будут использоваться лишь непродолжительное время, целесообразно реализовать средства поддержки клиента NFS как отдельный модуль. Поступив таким образом, вы сэкономите часть оперативной памяти в течение времени, когда средства NFS не используются, но монтирование внешних каталогов будет осуществляться несколько дольше, чем это было бы в том случае, если бы фрагмент кода, реализующий клиент NFS, был включен непосредственно в ядро.
Как вы, наверное, поняли, однозначного ответа на вопрос, надо ли включать коды поддержки опций непосредственно в ядро или их следует компилировать как отдельные модули, не существует. Я рекомендую вам сначала выяснить, насколько часто соответствующие средства будут использоваться в процессе работы системы. Если они должны использоваться постоянно, включайте их в основной файл ядра; если же они будут задействованы лишь эпизодически, компилируйте их в виде отдельных модулей. Если размер ядра становится слишком велик и при его загрузке средствами LOADIN (DOS-утилита для загрузки Linux) возникают проблемы, следует отдать предпочтение модульной организации ядра. Возможность загрузки с помощью LOADIN желательно сохранить, так как это поможет справиться с некоторыми проблемами.