Читать онлайн «Энциклопедия разработчика модулей ядра Linux»

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

Хорошо, добро пожаловать в клуб. Я однажды имел такой указатель, который стер мне важный каталог под DOS, и я не вижу, почему Linux должна быть более безопасной.

Предупреждение: я написал это и проверил программу под версиями 2.0.35 и 2.2.3 ядра, запущенного на Pentium. Главным образом это должно работать на других CPU и на других версиях ядра, по крайней мере версий 2.0.x или 2.2.x, но я не могу обещать что-нибудь. Одна исключительная ситуация: глава 11, которая не должна работать на архитектуре не x86.

Этот документ для тех, кто хочет писать модули ядра. Хотя я буду касаться в нескольких местах того, как многие задачи выполнены в ядре, это не моя цель. Имеется достаточно много хороших источников, авторы которых проделали работу лучшую чем та, которую я мог бы сделать.

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

Ядро имеет большое количество программирования, и я полагаю, что программисты должны читать по крайней мере некоторые его исходные файлы и понимать их. Сказав это, я также верю в значение игры с системой сначала и выяснением вопросов позже. Когда я узнаю новый язык программирования, я не начинаюсь с чтения библиотечного кода, а пишу маленькую программу `hello, world'. Я не вижу, почему начинающий разбираться с ядром должен быть действовать иначе.

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

1. Раздел изменений, 0.3.

2. Как найти младший номер устройства, 2.

3. Введено объяснение различия между символом и файлами устройства, 2

4. Makefile'ы для модулей ядра, 1.1.

5. Симметричная многопроцессорность, 12.

6. Глава `Плохие идеи', 13.

1. Поддержка версии 2.2 ядра во всех главах.

2. Исходный код примеров для разных версий ядра, 2.1.

3. Разница между версиями 2.0 и 2.2, A.

4. Модули ядра в нескольких файлах исходников, 1.2.

5. Предложение, как избежать беспорядка с системными вызовами при выдаче команды rmmod, 7.

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

TEX скелет для этой книги был бесстыдно захвачен из руководства `Linux Installation and Getting Started', где работа в TEX была выполнена Matt Welsh.

Моя благодарность Linus Torvalds, Richard Stallman и всем другим людям, кто сделали возможным для меня выполнить операционную систему высокого качества на моем компьютере и получить ее исходный текст, как нечто само собой разумеющееся (да, право, зачем я говорю это?).

Я не могу внести в список каждого, кто послал по e-mail мне сообщение, и если я не вписал именно Вас, я приношу извинения заранее. Следующие люди были особенно полезны:

• Frodo Looijaard из Нидерландов За сервер с кучей информации и полезных советов по ядрам версий 2.1.x.

• Stephen Judd из Новой Зеландии За правку орфографии.

• Magnus Ahltorp из Швеции За исправления, касательно разницы между символьными и блочными устройствами.

• Emmanuel Papirakis из Квебека, Канада за перенос всех примеров в версию 2.2 ядра.

• Frodo Looijaard из Нидерландов за сообщение как создать многофайловый модуль ядра (1.2).

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

Традиционно все учебники программирования начинаются с программы "Hello, world!". Я не знаю, что случается с людьми, которые порывают с этой традицией, и думаю, что безопаснее не выяснять. 

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

hello.c

/* hello.c

* Copyright (C) 1998 by Ori Pomerantz

*

* "Hello, world" - версия для модуля ядра.

*/

/* The necessary header files */

/* Standard in kernel modules */

#include <linux/kernel.h> /* We're doing kernel work */

#include <linux/module.h> /* Specifically, a module */

/* Deal with CONFIG_MODVERSIONS */

#if CONFIG_MODVERSIONS==1

#define MODVERSIONS

#include <linux/modversions.h>

#endif

/* Initialize the module */

int init_module() {

 printk("Hello, world - this is the kernel speaking\n");

 /* If we return a non zero value, it means that

 * init_module failed and the kernel module

 * can't be loaded */

 return 0;

}

/* Cleanup - undid whatever init_module did */

void cleanup_module() {

 printk("Short is the life of a kernel module\n");

}

Модуль не яявляется независимой программой, а представляет собой объектный файл, который будет прилинкован к ядру во время выполнения. В результате, они должны компилироваться с опцией -c. Все модули должны компилироваться с некоторыми определенными символами. 

• __KERNEL__ — Этот символ сообщает файлам заголовка, что этот код будет выполнен в ядерном режиме (нравится мне такое определение), а не как часть процесса пользователя.

• MODULE — Этот символ сообщает файлам заголовка, что надо дать соответствующие определения для модуля.

• LINUX — Технически это не необходимо. Однако, если Вы когда-либо захотите написать серьезный модуль, который компилируется на больше чем одной операционной системе, вы будете счастливы, что Вы сделали данное определение. Это позволит Вам делать условную трансляцию частей, которые являются OS-зависимыми. 

Имеются другие символы, которые должны быть включены или наоборот выключены в зависимости от параметров с которыми компилировалось ядро. Если вы не уверены, как ядро компилировалось, посмотрите в /usr/include/linux/config.h

• __SMP__ — Симметричная многопроцессорная обработка. Этот символ должен быть определен, если Вы компилируете модуль для ядра, которое было скомпилировано с опцией «Поддержка SMP» (даже если работать оно будет на однопроцессорной машине). Если Вы используете симметричную многопроцессорную обработку, имеются другие хитрости, которые Вы должны предусмотреть (см. главу 12).

• CONFIG_MODVERSIONS — Если CONFIG_MODVERSIONS разрешен, Вы должны иметь определить его при компиляции модуля и включить /usr/include/linux/modversions.h. Это может быть также выполнено кодом непосредственно. 

Makefile 

# Makefile для базисного ядерного модуля

CC=gcc

MODCFLAGS := -Wall -DMODULE -D__KERNEL__ -DLINUX

hello.o:        hello.c /usr/include/linux/version.h

                $(CC) $(MODCFLAGS) -c hello.c

                echo insmod hello.o to turn it on

                echo rmmod hello to turn if off