1.1. Назначение драйвера устройства

Как программист, вы постоянно должны будете идти на компромисс, выбирая между временем, затрачиваемым на программирование и универсальностью драйвера. Вас может удивить употребление термина "универсальный" по отношению к драйверу. Но нам нравится этот термин, поскольку он подчеркивает, что основное назначение драйвера устройства заключается в реализации тактики, а не стратегии.

Разделение тактики и стратегии -- одна из замечательных черт дизайна Unix. Значительная часть задач может быть разбита на две части: "какие возможности следует обеспечить" (тактика) и "как эти возможности использовать" (стратегия). Если эти две подзадачи решаются в разных частях программы или даже разными программами, то такой программный пакет намного проще развивать и адаптировать под изменяющиеся потребности.

Например, управление графическим дисплеем в Unix производит X-сервер, который работает с аппаратным окружением и предоставляет обобщенный инерфейс для пользовательских программ. Оконный менеджер осуществляют стратегию, ничего не зная об имеющихся аппаратных средствах. Разные люди могут использовать один и тот же оконный менеджер на различной аппаратуре, а различные пользователи могут использовать разные оконные менеджеры на одной и той же рабочей станции. Даже такие, отличные друг от друга окружения рабочего стола, как KDE и GNOME могут прекрасно сосуществовать вместе. Другой пример -- многоуровневая архитектура стека протоколов TCP/IP. Операционная система предоставляет абстракцию сокетов, которая не реализует никакой стратегии по обработке получаемых или передаваемых данных, в то время как за предоставление конкретных сетевых услуг отвечают конкретные серверы (реализующие свои стратегии).

Более того, такой сервер как ftpd реализует механизм (тактику) передачи файлов, в то время как пользователи могут использовать самые разнообразные клентские программы (и даже написать свою), обеспечивающие удобный интерфейс для передачи файлов (стратегия).

Такое же разделение относится и к драйверам. Драйвер НГМД (floppy) не реализует стратегии. Его назначение -- представить дискету как непрерывный массив блоков данных. Более высокие уровни операционной системы реализуют стратегию работы с дискетой -- обращаться ли к ней напрямую или посредством файловой системы, а также решают вопрос -- могут ли пользователи монтировать файловую систему на дискете. Поскольку разные среды работают с аппаратурой по-разному, очень важно, чтобы драйверы были свободны от принятия стратегических решений настолько, насколько это возможно.

При написании драйвера, программист должен обращать особое внимание на фундаментальный аспект: код ядра, предоставляющий доступ к аппаратуре, не должен заниматься реализацей стратегических решений для пользователей, поскольку пользователи могут иметь совершенно различные потребности. Драйвер должен обеспечивать доступ к аппаратуре, оставляя решение проблемы о том как ее использовать прикладным программам. Универсализм драйвера заключается в том, чтобы обеспечить доступ к возможностям аппаратуры не накладывая дополнительных ограничений. Иногда, однако, приходится выполнять реализацию отдельных стратегических решений. Например, драйвер дискретного ввода-вывода сможет получать-выдавать данные только побайтно, если не добавить дополнительный код, который будет обрабатывать отдельные биты.

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

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

В действительности, значительная часть драйверов выпускается совместно с прикладными программами, которые помогают сконфигурировать доступ к конкретному устройству. Эти программы могут быть и простыми утилитами командной строки и сложными приложениями с графическим интерфейсом пользователя. В качестве примеров можно привести утилиту tunelp, для настройки драйвера параллельного порта принтера и графическую утилиту cardctl, которая входит в состав пакета драйвера PCMCIA. Зачастую клиентские бмблиотеки реализуют дополнительные возможности, которые не являются составной частью драйвера.

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

1.2. Строение ядра

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

Одна из замечательных особенностей ядра Linux -- возможность расширять свою функциональность во время исполнения. Это означает, что вы можете добавить дополнительные возможности в ядро прямо во время работы системы.

Код, который добавляется в ядро во время исполнения, называется модуль. Ядро Linux предоставляет поддержку для разных типов (классов) модулей, для драйверов устройств в том числе. Каждый модуль представляет из себя файл с объектным кодом (не связанным в исполняемый модуль, т.е. не прошедший стадию линковки), который может быть динамически внедрен в работающее ядро с помощью программы insmod, а затем удален из ядра программой rmmod.

На рисунке выше показаны разные классы модулей, отвечающих за решение различных задач. Говорят, что модуль принадлежит определенному классу согласно предлагаемым функциональным возможностям.

1.3. Классы устройств и модулей

Традиционно, Unix разделяет все устройства на три основных типа. Каждый модуль, как правило, реализует функциональность одного из этих типов и отсюда может классифицироваться как символьный модуль, блочный модуль или сетевой модуль. Это деление не жесткое, программист может создать один большой модуль, в котором будет реализовано несколько различных драйверов. Но обычно хорошие программисты создают отдельные модули для каждого случая, поскольку декомпозиция -- есть ключевой момент масштабируемости и расширяемости.

Ниже приводятся краткие описания этих трех классов:

В Linux существуют и другие классы модулей драйверов, которые добавляют в ядро возможность взаимодействия с определенными типами устройств. Из таких нестандартных классов устройств наиболее часто встречается SCSI (Small Computer Systems Interface). Хотя внешние устройства, связанные с шиной SCSI, и отображаются в каталоге /dev, в виде символьных или блочных устройств, тем не менее, как и в случае с сетевыми интерфейсами, внутренняя программная организация отличается очень сильно.

Так же, как сетевые платы предоставляют свои возможности сетевой подсистеме, контроллер SCSI предоставляет в распоряжение подсистеме SCSI возможность доступа к SCSI-устройствам. SCSI -- это протокол взаимодействия между компьютером и переферийными устройствами. Любое SCSI-устройство откликается на этот протокол, вне зависимости от того, какой контроллер установлен в компьютер. Ядро отображает файловые операции на протокол взаимодействия SCSI. Разработчик SCSI драйвера должен реализовать отображение между абстракцией SCSI и физическим кабелем. Это отображение зависит от типа контроллера, но не зависит от типа устройства, подключенного к контроллеру.

Ряд других классов драйверов устройств были добавлены не так давно. Сюда можно отнести USB, FireWire и I2O. Как и в случае SCSI, разработчики ядра собрали воедино особенности, характерные для всего класса и экспортировали их для разработчиков драйверов, чтобы избежать дублирования работы и уменьшить вероятность появления ошибок, чем упростили процесс написания таких драйверов.

Помимо драйверов устройств, пожалуй самым важным классом модулей в Linux являются файловые системы. Тип файловой системы обусловливает способ организации информации на блочном устройстве. Это -- не драйвер устройства, здесь нет никакого устройства, которое было бы связано со способом размещения информации. Тип файловой системы -- это программный драйвер, потому что он отображает структуры данных нижнего уровня на структуры данных верхнего уровня. Файловая система определяет -- какой длины могут быть имена файлов и какая информация о каждом из файлов должна храниться. Файловая система должна реализовать самый нижний уровень системных вызовов для доступа к каталогам и файлам, путем отображения их имён (и иной информации, такой как права доступа и пр.) в структуры данных, которые записываются в блоки данных. Такой интерфейс полностью независим от физической передачи данных с/на диск (или другой носитель), которая выполняется драйвером блочного устройства.

Если вы задумаетесь над тем, насколько сильно Unix зависит от концепции файловой системы, вы поймете насколько она важна для работы операционной системы. Функции обработки информации, хранящейся в файловой системе находятся на самом нижнем уровне в иерархии ядра и имеют очень важное значение. Даже если вы напишете драйвер для своего CD-ROM, он окажется совершенно бесполезен, если не будет возможности выполнить ls или cp. Linux поддерживает модули файловых систем, которые реализуют различные файловые операции. Однако, вам едва ли придется писать свой модуль файловой системы, поскольку ядро Linux включает в себя код довольно большого числа наиболее популярных файловых систем.

1.4. Проблемы безопасности

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

Проблема безопасности имеет два основных понятия: случайное нанесение ущерба и умышленное. Первое понятие -- ущерб, причиненный в результате ошибочных действий пользователя или непреднамеренных ошибок в программе. Второе -- ущерб, причиненный в результате предумышленных действий программиста, который мог умышленно написать вредоносный код. Другими словами -- следует остерегаться запускать программы, полученные от незнакомых лиц, да еще под учетной записью root. Доступность компилятора не должна расцениваться как "дыра" в системе защиты. "Дыра" может появиться, когда запускается скомпилированная программа. Вы должны быть очень внимательны при обращении с модулями, потому что модулям ядра доступно практически все, как и суперпользователю.

Любая проверка безопасности производится кодом ядра. Если ядро имеет бреши в системе безопасности, то и система в целом будет иметь бреши. В официальных версиях ядра только автороизованный пользователь имеет право загружать модули -- проверка прав производится системным вызовом create_module. Таким образом, на официальных версиях ядра только суперпользователь или злоумышленник, который завладел привилегиями суперпользователя, сможет исполнить привелигированный код (в ядрах серии 2.0 только суперпользователю было позволено запускать привелигированный код, начиная с версии 2.2 ядром выполняются более изощренные проверки).

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

Вы так же должны стремиться не допускать ошибки в коде, которые могут стать дырами в системе безопасности. Язык программирования C "облегчает" внесение некоторых видов ошибок. Например, немало проблем с безопасностью породила ошибка переполнения буфера. Эта ошибка связана с забывчивостью программиста, который забывает выполнить проверку количества данных, записываемых в буфер. В результате данные могут быть записаны далеко за пределы памяти, отведенной под буфер, что приводит к порче других данных. Такого рода ошибки могут поставить под угрозу работоспособность системы в целом. К счастью, уйти от таких ошибок довольно просто, особенно в контексте драйвера устройства, для которого интерфейс с пользователем четко определен.

Следует постоянно помнить и о некоторых других мерах предосторожности. К любой информации, введенной пользователем, вы должны относиться с большим подозрением -- никогда не доверяйте этой информации и всегда проверяйте ее, если это возможно. Будьте внимательны при работе с неинициализированной памятью -- любой участок памяти, полученной от ядра, должен забиваться нулями или инициализироваться каким-либо другим способом прежде, чем эта память будет передана пользовательскому процессу или устройству. Если ваше устройство выполняет интерпретацию данных, убедитесь, что пользователь не может послать ничего, что могло бы поставить под угрозу работоспособность системы. Наконец, подумайте о возможных побочных эффектах (например, перепрошивка firmware в ПЗУ устройства, форматирование диска и т.п.). Доступность операций, которые могут вызвать такие побочные эффекты, должна ограничиваться узким кругом привелигированных пользователей.

Будьте внимательны при работе с программным обеспечением, полученным от третьих лиц, особенно это касается ядра, поскольку каждый, кто имеет доступ к исходным текстам, может внести вредоносный код и скомпилировать его. Собранным ядрам, входящим в состав официальных дистрибутивов, вы обычно можете доверять, но не доверяйте ядрам, собранным незнакомыми лицами. Злоумышленник может внести изменения в код вызова create_module и получить возможность загружать модули ядра, открывая таким образом "черный ход" для запуска вредоносных программ.

Здесь следует упомянуть, что ядро может быть собрано вообще без поддержки загружаемых модулей. В этом случае, вам естесственно придется скомпилировать все необходимые драйверы статически. Начиная с версии 2.2, ядро допускает отключение возможности загрузки модулей сразу после загрузки системы через соответствующий механизм.

1.5. Нумерация версий

Перед тем как углубиться в программирование, нам хотелось бы сказать несколько слов о принципах нумерации версий, используемых в Linux и о версиях, которые охватываются этой книгой.

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

Для запуска примеров, которые будут встречаться по ходу изложения материала, вам не потребуется знать версии инструментальных средств, но это замечание не относится к ядру -- наши примеры смогут быть опробованы практически в любом современном дистрибутиве Linux. Мы не будем развивать дискуссию в этом направлении, поскольку в вашем распоряжении имеется файл Documentation/Changes (в дереве каталогов с исходными текстами ядра) где вы всегда сможете найти исчерпывающую информацию при возникновении проблем.

Основной интерес для нас представляют ядра, имеющие четные номера версий (т.е. 2.2.x и 2.4.x). Это стабильные версии ядра, предназначенные для включение в состав дистрибутивов и широкого использования. Нечетные версии (такие как 2.3.x) наоборот являются нестабильными и предназначены для разработчиков. Эти версии устаревают очень быстро, порядка нескольких дней или около того.

Эта книга охватывает ядра версий 2.0.x, 2.2.x и 2.4.x. Однако основное внимание будет уделяться ветке 2.4 (текущая стабильная ветка на момент написания книги), всем ее особенностям, доступным для разработчиков драйверов. Мы попробуем показать особенности ветки 2.2 в тех местах, где они имеют расхождения с веткой 2.4. Мы так же будем обращать ваше внимание на возможности недоступные в ветке 2.0. Вообще код, который будет продемонстрирован в книге, опробовался в широком диапазоне версий ядра. Он был полностью протестирован на ядре 2.4.4, где это было возможно -- на ядре 2.2.18 и 2.0.38.

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

Еще одна особенность Linux -- его независимость от аппаратной платформы. Linux -- это не просто "клон UNIX для PC". Он успешно работает на процессорах Alpha и SPARC, на платформах 68000 и PowerPC и на многих других. В этой книге не обсуждается какая-либо конкретная платформа, навколько это было возможно сделать. Все примеры тестировались на различных платформах, таких как PC, Alpha, ARM, IA-64, M68k, PowerPC, SPARC, SPARC64 и VR41xx (MIPS). Поскольку код проверялся как на 32-х битных так и на 64-х битных процессорах, он должен компилироваться и запускаться и на других платформах. Если какой-либо пример будет работать не на всех платформах, то это будет явно указываться нами.

1.6. Лицензионные соглашения

Linux распространяется на основе GNU General Public License (GPL), которая была разработана Free Software Foundation для проекта GNU. Она позволяет любому распространять и даже продавать продукты, выпущенные на основе GPL, при условии, что покупатель, вместе с бинарными файлами, сможет получить и исходные тексты. Кроме того, если программный продукт является производным от продукта, выпущенного на основе GPL, он так же должен распространяться на основе GPL.

Основная цель этой лицензии -- распространение знаний, разрешая каждому изменять программы по своему усмотрению, вместе с тем допуская распространение программного обеспечения на коммерческой основе. Несмотря на простые цели лицензии, споры о ней и ее применении по-прежнему не прекращаются. Если вы пожелаете ознакомиться с текстом лицензии, вы сможете найти ее в своем дистрибутиве, как одно из мест -- /usr/src/linux в файле COPYING.

Модули не являются частью ядра Linux, а посему вы не обязаны лицензировать их под GPL. Модули обращаются к ядру, используя предопределенный интерфейс, но не так как используют ядро пользовательские программы, обращаясь к нему через системные вызовы. Освобождение от лицензирования под GPL относится только к модулям ядра, потому что они использую только официально опубликованный интерфейс. Модули, которые используют более глубинные механизмы ядра, подпадают под определение "derived work" (производный продукт) лицензии GPL.

Короче говоря, если ваш код входит в состав ядра, то вы должны использовать GPL, как только вы его выпустите. Если вы распространяете ваш код, то вы должны включить в комплект поставки исходные тексты -- всем, кто приобретает ваш пакет необходимо предоставить право пересобрать бинарные файлы. Если вы написали модуль ядра, то вы можете распространять его в виде скомпилированных файлов, но это не совсем практично, поскольку модули, как правило, необходимо пересобирать заново для каждой версии ядра (подробнее этого вопроса мы коснемся в главе 2, в разделе "Зависимость версий" и в главе 11, в разделе " Контроль версий в модулях"). Новые версии ядра, даже стабильные, зачастую отказываются работать с модулями, предкомпилированными с другими версиями ядра, требуя их пересборки. Линус Торвальдс публично заявил, что не видит в этом никакой проблемы, поскольку скомпилированные модули по-прежнему сохраняют свою работоспособность в той версии ядра, под которую они собирались. Как разработчик вы сделаете благое дело, если предоставите свой исходный код в общее пользование.

Почти весь код, который приводится в данной книге, может вами свободно распространяться как в исходном виде, так и в скомпилированном. И никто -- ни мы, ни O Reilly & Associates не сохраняют за собой право на любой продукт, производный от данного кода. Все программы доступны для свободного скачивания на ftp://ftp.ora.com/pub/examples/linux/drivers/. Точные условия лицензирования указаны в файле LICENSE.

Если примеры используют части кода ядра, то они подпадают под условия GPL. Комментарии в примерах напоминают об этом в недвусмысленной форме. Это относится только к паре файлов, которые приводятся во второстепенных разделах данной книги.

1.7. Как присоединиться к сообществу разработчиков ядра

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

Центральное место встречи всех разработчиков ядра -- список почтовой рассылки linux-kernel. Все основные разработчики ядра подписаны на эту рассылку, в том числе и Линус Торвальдс. Единственно хотим отметить, что эта рассылка не для слабонервных -- ежедневный объем может доходить до 200 сообщений и больше. Тем не менее эта расслка окажется весьма полезной для тех, кто хочет постоянно оставаться в курсе событий, а кроме того, эта рассылка является источником очень ценной информации.

Чтобы подписаться на рассылку, следуйте инструкциям, приводимым в FAQ, по адресу http://www.tux.org/lkml. Пожалуйста, прочитайте FAQ до конца, здесь содержится много полезных сведений. Разработчики занятые люди и они более склонны помогать тем, кто имеет хотя бы начальные знания.

1.8. Обзор книги

Со следующей главы мы начинаем обсуждать вопросы, касающиеся программирования для ядра. В этой главе будут рассмотрены вопросы модульной архитектуры и показан пример простого модуля ядра. В главе 3 мы погоаорим о драйверах символьных устройств и продемонстрируем полный текст простого драйвера, который может просто читать и писать данные из/в память. Использование памяти вместо аппаратного устройства позволит вам опробовать код без необходимости подключения дополнительной аппаратуры.

Методы отладки и необходимые инструменты программиста будут рассмотрены в главе 4. Затем, получив необходимые знания об отладке, мы двинемся дальше и в главе 5 рассмотрим некоторые дополнительные особенности, характерные для драйверов символьных устройств, такие как блокирующие операции, функции select и ioctl.

Прежде чем приступить к работе с аппаратной частью компьютера, мы опять немного углубимся в ядро. В главе 6 мы расскажем об управлении временем в ядре и в главе 7 -- о способах выделения памяти.

Затем мы сосредоточим наше внимание на аппаратной части. В главе 8 мы рассмотрим управление портами ввода-вывода, буферами памяти и затем в главе 9 перейдем к прерываниям. При изучении этой главы нам потребуется эмулировать наличие дополнительной аппаратуры, чтобы проверить прерывания. Мы постарались свести использование дополнительных аппаратных средств к минимуму, так что вам достаточно будет лишь втсавить в параллельный порт одну единственную перемычку. Надеемся, что для вас это не будет большой проблемой.

В главе 10 мы дадим ряд дополнительных советов по написанию модулей и коснемся проблемы переносимости.

Во второй части книги мы еще глубже погрузимся в ядро и в главе 11 обсудим проблему модульной архитектуры ядра.

В главе 12 опишем блочные драйверы, отдельно останавливаясь на аспектах, отличающих драйверы блочных устройств от драйверов символьных устройств. Затем, в главе 13 мы рассмотрим дополнительные способы управления памятью: mmap и DMA (Direct Memory Access -- Прямой Доступ к Памяти). На этом обсуждение драйверов блочных и символьных устройств будет закончено.

Затем мы представим вам третий основной класс драйверов. В главе 14 мы поговорим о некоторых особенностях сетевых интерфейсов и рассмотрим код типичного драйвера сетевой платы.

Некоторые особенности драйверов напрямую зависят от интерфейсной шины, к которой подключаются устройства, таким образом, глава 15 послужит кратким обзором основных, наиболее часто встречающихся, типов интерфейсных шин. Особое внимание будет уделено поддержке шин PCI и USB.

И наконец глава 16 представляет собой тур по исходным текстам ядра: она предназначена для тех, кто желает понять его архитектуру, но боится затеряться в огромном количестве исходных текстов.

2.1. Модули ядра и прикладные программы

Прежде чем двинуться дальше, необходимо подчеркнуть различия, иемеющиеся между модулями ядра и прикладными программами.

Приложение выполняется как цельная задача, от начала и до конца. Модуль же просто регистрирует себя самого в ядре, подготавливая его для обслуживания возможных запросов и его функция "main" завершает свою работу сразу же после вызова. Другими словами, задача функции init_module (точка входа) состоит в подготовке функций модуля для последующих вызовов. Она как бы говорит ядру: "Эй! Я здесь! Вот то, что я могу делать!". Вторая точка входа в модуль -- cleanup_module вызывается непосредственно перед выгрузкой модуля. Она сообщает ядру: "Я ухожу! Больше не проси меня ни о чем!". Возможность выгружать модули -- это одна из особенностей модульной архитектуры, которую вы наверняка оцените по достоинству, поскольку она поможет вам значительно сократить время, затрачиваемое на разработку модуля. С ее помощью вы сможете проверять новые версии модуля без необходимости тратить свое драгоценное время на перезагрузку системы.

Как программист, вы знаете, что приложение может вызывать функции, которые не определены в самой программе. На стадии связывания (линковки) разрешаются все внешние ссылки, уходящие во внешние библиотеки. Функция printf -- одна из таких функций, которая определена в библиотеке libc. Модули так же проходят стадию связывания, но только с ядром, и могут вызывать только те функции, которые экспортируются ядром. Функция printk, использованная в примере hello.c, определена в ядре и импортируется модулем. Она очень похожа на своего сородича из libc, с небольшими отличиями, главное из которых состоит в отсутствии поддержки вывода чисел с плавающей точкой [2]

На рисунке ниже показана схема вызова функций и как используются указатели на функции в модуле при добавлении его в ядро.

Поскольку модуль не связывается ни с одной из стандартных библиотек, исходные тексты модуля не должны подключать обычные заголовочные файлы. В модулях ядра могут использоваться только те функции, которые экспортируются ядром. Все заголовочные файлы, которые относятся к ядру, расположены в каталогах include/linux и include/asm, внутри дерева каталогов с исходными текстами ядра (как правило это каталог /usr/src/linux). Ранние версии Linux (основанные на libc версии 5 и более ранних) устанавливали символические ссылки из /usr/include/linux и /usr/include/asm на фактические каталоги из исходных текстов ядра, таким образом дерево заголовочных файлов libc могло ссылаться на заголовочные файлы ядра. Это позволяло подключать заголовочные файлы ядра в пользовательские приложения тогда, когда в этом возникала необходимость.

Но даже теперь, когда заголовочные файлы ядра отделены от заголовочных файлов, используемых прикладными программами, все равно иногда возникает необходимость включения их в программы, работающие в пространстве пользователя, чтобы воспользоваться определениями, отсутствующими в обычных заголовочных файлах. Однако большая часть определений из заголовочных файлов ядра относится исключительно к ядру и "невидима" для обычных приложений, поскольку доступ к этим определениям заключен в блоки #ifdef __KERNEL__. Это кстати одна из причин, почему необходимо определять символ __KERNEL__ при сборке модуля.

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

Разработчики, работающие с большими программными пакетами (такими как ядро), должны избегать "загрязнения" пространства имен (namespace). Под "загрязнением" пространства имен понимается внедрение множества имен функций и переменных, с глобальной областью видимости, значение которых не интутивно и трудноразличимо. Программист, который работает с такими приложениями, тратит огромное количество умственных сил на то, чтобы запомнить "зарезервированные" имена и придумать свои уникальные названия. Коллизии имен могут породить трудноуловимые ошибки, начиная от того, что модуль просто отказывается загружаться, и заканчивая весьма причудливыми сообщениями.

Разработчик не должен допускать появления таких ошибок, поскольку даже маленький модуль линкуется с целым ядром. Лучший способ избежать "загрязнения" пространства имен -- это объявлять все имена как static и использовать префиксы для придания уникальности именам с глобальной областью видимости. Проблемы, связанные с управлением областью видимости, будут обсуждаться в разделе "Таблица имён ядра", в этой же главе.

Так же хорошей практикой считается использование своих предопределенных префиксов для всех локальных имен в модуле, это поможет вам в процессе отладки. Они позволят вам экспортировать имена, без "загрязнения" пространства имен, в процессе тестирования. Префиксы, используемые в исходных текстах ядра, всегда состоят только из символов нижнего регистра. Мы так же будем придерживаться этого соглагшения (большая часть версий insmod экспортирует нестатические имена, придавая им глобальную область видимости).

И наконец последнее отличие модулей ядра от обычных приложений, на котором мы хотим остановиться, состоит в том, как обрабатываются ошибки. Например, ошибка segmentation fault, возникающая в приложении может быть отслежена и устранена без особых проблем, а вот в модуле ядра практически любая ошибка может стать фатальной для всей системы. В разделе "Отладка системных ошибок", главы 4, мы подробнее остановимся на проблеме отладки.

printk("The process is \"%s\" (pid %i)\n", current->comm, current->pid); 
  

2.2. Компиляция и загрузка

Остальная часть главы посвящена созданию законченного модуля. Этот модуль не принадлежит ни одному из классов, описанных в разделе Классы устройств и модулей главы 1. Этот модуль называется skull, сокращенно от "Simple Kernel Utility for Loading Localities".

Ранее мы уже познакомились с функциями init_module и cleanup_module. Теперь мы создадим Makefile, с помощью которого будем собирать свой модуль.

Для начала определим символ препроцессора __KERNEL__, прежде чем будем поключать какие-либо заголовочные файлы. Как уже говорилось ранее, большая часть заголовочных файлов ядра недоступна без этого определения.

Еще один очень важный символ -- MODULE, который должен быть определен до подключения файла linux/module.h (за исключением случаев, когда драйвер компилируется с ядром статически). Эта книга не рассматривает вопрос статической компиляции драйверов в ядро, поэтому в наших примерах всегда необходимо определять символ MODULE.

Если вы собираете модуль для многопроцессорной системы, то необходимо определить символ __SMP__ до подключения заголовочных файлов. Начиная с версии 2.2 выбор между однопроцессорным и многопроцессорным вариантами можно определить через конфигурационный файл. Таким образом, определение символа __SMP__ можно оформит так:

#include <linux/config.h> 
#ifdef CONFIG_SMP 
#define _ _SMP_ _ 
#endif
  

Вам так же надлежить указать флаг компилятора -O, потому что некоторые из функций объявлены в заголовочных файлах как inline, а gcc не сможет развернуть эти функции, если оптимизация запрещена. Кроме того, вам может понадобиться флаг -g, чтобы иметь возможность отладки кода, который использует inline функции. [3]

Вам так же необходимо убедиться, что версия компилятора соответствует версии ядра. Требования к версии компилятора вы найдете в файле Documentation/Changes. Процессы развития компилятора и ядра протекают одновременно, только разработки ведутся разными командами, поэтому иногда изменения в компиляторе могут привести к появлению ошибок в ядре. Некоторые дистрибутивы распространяются с новейшими версиями компилятора, который пока еще плохо справляется со сборкой ядра. В этом случае в дистрибутив, как правило, вкладывается отдельный пакет с компилятором (обычно под именем kgcc), предназначенным для сборки ядра.

И наконец, чтобы предотвратить появление досадных ошибок, мы предлагаем использовать флаг Wall (all warnings -- все предупреждения), который поможет вам исправить все участки кода, порождающие предупреждения компилятора, пусть даже они вызваны лишь привычным для вас стилем оформления программ. При написании кода ядра предпочтительным, безусловно является стиль, присущий самому Линасу Торвальдсу. Забавные и поучительные заметки по стилю оформления исходного кода вы найдете в файле Documentation/CodingStyle.

Все предлагаемые флаги компилятора лучше всего записать в виде переменной окружения CFLAGS, которую использует утилита make.

Кроме переменной CFLAGS, Makefile должен содержать правило для сборки объектного файла модуля из нескольких объектных файлов. Это правило потребуется только в том случае, если исходные тексты модуля хранятся в нескольких файлах, что нехарактерно для модулей. Если исходный текст вашего модуль находится в единственном файле, то можете просто пропустить правило, которое содержит ld -r. [4]

# Измените, если это необходимо, путь к исходным текстам ядра
# или укажите его в командной строке, при вызове утилиты "make"
KERNELDIR = /usr/src/linux 

include $(KERNELDIR)/.config 

CFLAGS = -D_ _KERNEL_ _ -DMODULE -I$(KERNELDIR)/include -O -Wall 

ifdef CONFIG_SMP 
  CFLAGS += -D_ _SMP_ _ -DSMP 
endif 

all: skull.o 

skull.o: skull_init.o skull_clean.o 
  $(LD) -r $^ -o $@ 
  
clean: 
  rm -f *.o *~ core 
  

Если вы не знакомы с утилитой make, у вас наверняка возникнет вопрос: "А где же правила, управляющие компиляцией .c файлов?" Дело в том, что явное указание этих правил необязательно, поскольку make по-умолчанию формирует .o файлы из .c, без необходимости явного указания правил. Во время компиляции используются компилятор $(CC) и флаги компиляции $(CFLAGS).

5.1. Управление доступом к файлам устройств