15.2. Компиляция для отладки Для использования отладчика исходного кода, отлаживаемый исполняемый файл должен быть откомпилирован с опцией компилятора -g. Эта опция заставляет компилятор внедрять в объектный код дополнительные отладочные идентификаторы; то есть

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

3.8.3. Компиляция ядра При установке из RPM-пакета мы получаем модульное ядро, в котором драйверы устройств могут быть как скомпилированы в одно целое с ядром, так и загружаться отдельно. Такое ядро медленнее в работе, но позволяет обновлять драйверы простой заменой

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

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

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

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

Например, если модули с именами М1,М2 содержат одноименные тип А, переменная В и подпрограмма С, то после подключения этих моделей USES обращения к А, В, С в этой ПЕ будут эквивалентны обращениям к объектам к модулю М2.

Но чтобы характеризовать корректность обращений к нужным одноименным объектам разных подключенных модулей целесообразно при обращении к модулю сначала указывать имя модуля, а через точку имя объекта: М1.А М1.В М1.С М2.В.

Очевидно, что весьма несложно разделить большую программу на две части (ПЕ), т.е. основная программа + модули.

Размещая каждую ПЕ в свой сегмент памяти и в свой дисковый файл.

Все объявления типов, а также тех переменных, которые должны быть доступны отдельным ПЕ (основной программе и будущим модулям) следует поместить в отдельный модуль с пустой исполняемой частью. При этом не следует обращать внимание на то, что какая-то ПЕ (например, модуль) не использует всех этих объявлений. В инициирующей части такого модуля могут быть включены операторы, связывающие файловые переменные с нестандартными текстовыми файлами (ASSIGN) и инициирующие эти файлы, т.е. указывающие для них обращения к передаче данных (RESET и REWRITE).

Первую группу других подпрограмм, например, несколько компактных функций следует поместить в 3 (по очереди) модуль, другие, например, процедуры общего назначения – в 4 модуль, и т.д.

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

В среде ТР имеются средства, управляющие различными способами компиляции модулей.

Compile Alt+F9 RUN Cntr+F9

Destination Memory

Эти режимы отличаются только способом связи и основной программой.

Режим Compile

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

При наличии Destination сохранены в памяти, то эти файлы остаются только в памяти, а дисковый файл не создается.

Однако гораздо проще создавать tpu –файлы заодно с компилятором всей программы с помощью других режимов, которые не требуют задания Disk для опции destination.

Режим Make

При компиляции в этом режиме предварительно (до компилирования основной программы) для каждого модуля проверяется:

1) Существования дискового tpu –файла; если его нет, то он создается автоматически путем компилирования исходного текста модуля, т.е. его pas-файл

2) Соответствие найденного tpu –файла исходному тексту модуля, куда могли быть внесены изменения; в противном случае tpu –файл автоматически создается заново

3) Неизменность интерфейсного раздела модуля: если он изменился, то перекомпилируются также все те модули (их исходные pas-файлы), в которых данный модуль указан в предложении USES.

Если изменение в исходных текстах модулей не было, то компилятор работы взаимодействует с этими tpu –файлами и использует время для компиляции.

Режим Build

В отличие от режима Make обязательно требует наличие исходных pas-файлов; проводит компиляцию (перекомпиляцию) каждого модуля и тем самым гарантирует учет всех изменений в текстах pas-файлов. Это увеличивает время компиляции программы в целом.

В отличии от режима сompile режим Make и Build позволяют начинать компилировать программу модульной структуры с любого заданного pas-файла (его и называют первичным) независимо от того, какой файл (или часть программы) находится в активном окне редактора. Для этого в пункте сompile выбирают опцию Primary file нажимают Enter и записывают имя первичного pas-файла и тогда компиляция начнется именно с этого файла.

Если же первичный файл так не указывается, то компиляция в режимах Make, Build и RUN возможно только в том случае, если в активном окне редактора находится основная программа.

Когда возникает необходимость создания мощной и надёжной системы на основе Linux (будь то обслуживание технологических процессов, веб-хостинга и т. д.), то очень часто приходится настраивать системное ядро таким образом, чтобы вся система работала более эффективно и надёжно. Ядро Linux хоть и является универсальным, однако бывают ситуации, когда его необходимо «подтюнинговать» по объективным причинам. Да и сама архитектура ядра это предполагает благодаря своей открытости. Таким образом, системные администраторы Linux – это те люди, которым важно знать и понимать некоторые общие аспекты конфигурирования ядра Linux.

Способы конфигурации ядра Linux

За время развития Linux постепенно сложились четыре основных способа для конфигурирования её ядра:

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

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

Настраиваемые параметры ядра

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

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

Но как и всё в системах UNIX и Linux, настройка параметров ядра по информационным каналам завязана на файловой системе. Чтобы просматривать конфигурацию ядра и управлять ею, в файловой системе в каталоге /proc/sys существуют специальные файлы. Это обычные файлы, но они играют роль посредников в предоставления интерфейса для динамического взаимодействия с ядром. Однако документация, касающаяся этого аспекта, в частности об описании конкретных параметров и их значений довольно скудна. Одним из источников, из которого можно почерпнуть некоторые сведения по этой теме, является подкаталог Documentation/sysent в каталоге с исходными кодами ядра.

Для наглядности стоит рассмотреть небольшой пример, показывающий, как через параметр ядра настроить максимальное число одновременно открытых файлов в системе:

$ cat /рrос/sys/fs/file-max 34916 $ sudo sh -c "echo 32768 > /proc/sys/fs/file-max"

Как можно видеть, к такому приёму можно довольно быстро привыкнуть и это не будет казаться чем-то очень сложным. Такой метод хоть и удобен, однако изменения не сохраняются после перезапуска системы.

Также можно использовать специализированную утилиту sysctl . Она позволяет получить значения переменных прямо из командной строки, либо список пар вида переменная=значение из файла. На этапе начальной загрузки утилита считывает начальные значения некоторых параметров, которые заданы в файле /etc/sysctl.conf . Более подробную информацию об утилите sysctl можно найти на страницах .

В следующей таблице приводятся некоторые настраиваемые параметры ядра:

Условные обозначения: F - /proc/sys/fs, N - /proc/sys/net/ipv4, К - /proc/sys/kernel, С - /proc/sys/dev/cdrom.

$ sudo sysctl net.ipv4.ip_forward=0

В результате выполнения этой команды будет отключено перенаправление IP-пакетов. Есть одна особенность для синтаксиса этой команды: символы точки в «net.ipv4.ip_forward» заменяют символы косой черты в пути к файлу ip_forward.

Когда нужно собирать новую версию ядра?

В настоящее время ядро Linux развивается очень быстро и бурно. Зачастую производители дистрибутивов не успевают внедрять в свои системы новые версии ядер. Как правило все новомодные «фишки» больше понадобятся любителям экзотики, энтузиастам, обладателям новинок устройств и оборудования и просто любопытствующим - т. е. преимущественно тем, в чьём распоряжении имеется обычный пользовательский компьютер.

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

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

Если же принято решение обновить версию ядра путём его самостоятельной сборки, то нужно выяснить, является ли данная версия стабильной. Раньше система нумерования версий ядра Linux была организована таким образом, что чётные номера версий означали стабильный выпуск, нечётные - ещё «сырой». В настоящее время этот принцип соблюдается далеко не всегда и выяснять этот момент следует из информации на официальном сайте kernel.org .

Конфигурирование параметров ядра

Конфигурация для будущей сборки ядра Linux хранится в файле.config. Мало кто занимается ручным созданием и редактированием этого файла, поскольку, во-первых: это сложный синтаксис, который далеко не самый «человекопонятный», и во-вторых: существуют способы для автоматической генерации конфигурации сборки ядра с удобным графическим (или псевдографическим) интерфейсом. Список основных команд для конфигурирования сборки ядра:

• make xconfig – рекомендуется, если используется графическая среда KDE. Весьма удобный инструмент;
• make gconfig – лучший вариант для использования в графической среде GNOME;
• make menuconfig – данную утилиту следует использовать в псевдографическом режиме. Она не так удобна, как две предыдущие, однако со своими функциями справляется достойно;
• make config – самый неудобный «консольный» вариант, выводящий запросы на задание значений каждого параметра ядра. Не позволяет изменить уже заданные параметры.

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

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

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

В результате работы вышеуказанных команд будет сгенерирован файл.conf, фрагмент содержимого из которого может быть следующим:

# # Automatically generated file; DO NOT EDIT. # Linux/x86 4.20.7 Kernel Configuration # # # Compiler: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70300 CONFIG_CLANG_VERSION=0 CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y

Как можно видеть, в данном коде нет ничего привлекательного для ручного редактирования, о чём даже упоминает запись комментария в начале файла.config. Символ «y» в конце какой-либо из строк указывает, что соответствующий компонент будет скомпилирован в составе ядра, «m» — как подключаемый модуль. Расшифровки или описания о каждом компоненте или параметре в файле.config не содержится - по этим вопросам следует изучать соответствующую документацию.

Компиляция ядра

Самое сложное в компиляции ядра Linux – это создание конфигурации сборки, поскольку нужно знать, какие компоненты подключать. Хотя использование команд make xconfig, make gconfig, make menuconfig и обеспечивает задание стандартной рабочей конфигурации, с которой система будет работать на большинстве аппаратных платформ и конфигураций. Вопрос лишь в том, чтобы грамотно задать конфигурацию ядра без ненужных и занимающих лишние ресурсы компонентов при его работе.

Итак, для успешного конфигурирования и компиляции ядра нужно выполнить следующие действия:

• перейти в каталог с исходными кодами ядра. Обычно «исходники» для ядра Linux помещаются в каталог /usr/src, либо можно скачать с сайта kernel.org в любое удобное место;
• выполнить команду make xconfig, make gconfig или make menuconfig;
• выполнить команду make dep (можно не выполнять для ядер версии 2.6.x и более поздних);
• выполнить команду make clean (для очистки от всего того, что может помешать успешной сборке);
• выполнить команду make;
• выполнить команду make modules_install;
• скопировать файл /arch/имя_архитектуры/boot/bzImage в /boot/vmlinuz. Здесь каталог /arch находится в каталоге с исходными кодами ядра Linux, имя_архитектуры - каталог, имеющий имя соответствующей архитектуры (указанной на этапе конфигурирования). Имя собранного бинарного образа ядра bzImage может быть другим;
• скопировать файл /arch/имя_архитектуры/boot/System.map в /boot/System.map;
• внести изменения в конфигурационные файлы системных загрузчиков /etc/lilo.conf (для LILO) или /boot/grub/grub.conf - для GRUB, а также добавить в них соответствующие конфигурационные и параметры загрузки для нового ядра.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

Модуль ядра Linux - это скомпилированный двоичный код, который вставляется непосредственно в ядро Linux, работая в кольце 0, внутреннем и наименее защищённом кольце выполнения команд в процессоре x86–64. Здесь код исполняется совершенно без всяких проверок, но зато на невероятной скорости и с доступом к любым ресурсам системы.

Не для простых смертных

Можно в основном забыть традиционные парадигмы разработки приложений. Кроме загрузки и выгрузки модуля, вы будете писать код, который реагирует на системные события, а не работает по последовательному шаблону. При работе с ядром вы пишете API, а не сами приложения.

У вас также нет доступа к стандартной библиотеке. Хотя ядро предоставляет некоторые функции вроде printk (которая служит заменой printf) и kmalloc (работает похоже на malloc), в основном вы остаётесь наедине с железом. Вдобавок, после выгрузки модуля следует полностью почистить за собой. Здесь нет сборки мусора.

Необходимые компоненты

Во-вторых, нужна или отдельная физическая машина, или виртуальная машина. Лично я предпочитаю работать на виртуальной машине, но выбирайте сами. Не советую использовать свою основную машину из-за потери данных, когда сделаете ошибку. Я говорю «когда», а не «если», потому что вы обязательно подвесите машину хотя бы несколько раз в процессе. Ваши последние изменения в коде могут ещё находиться в буфере записи в момент паники ядра, так что могут повредиться и ваши исходники. Тестирование в виртуальной машине устраняет эти риски.

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

Установка среды разработки

Apt-get install build-essential linux-headers-`uname -r`
Устанавливаем самые важные инструменты разработки и заголовки ядра, необходимые для данного примера.

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

Начинаем

Mkdir ~/src/lkm_example cd ~/src/lkm_example
Запустите любимый редактор (в моём случае это vim) и создайте файл lkm_example.c следующего содержания:

#include #include #include MODULE_LICENSE(“GPL”); MODULE_AUTHOR(“Robert W. Oliver II”); MODULE_DESCRIPTION(“A simple example Linux module.”); MODULE_VERSION(“0.01”); static int __init lkm_example_init(void) { printk(KERN_INFO “Hello, World!\n”); return 0; } static void __exit lkm_example_exit(void) { printk(KERN_INFO “Goodbye, World!\n”); } module_init(lkm_example_init); module_exit(lkm_example_exit);
Мы сконструировали самый простой возможный модуль, рассмотрим подробнее самые важные его части:

• В include перечислены файлы заголовков, необходимые для разработки ядра Linux.
• В MODULE_LICENSE можно установить разные значения, в зависимости от лицензии модуля. Для просмотра полного списка запустите:

  Grep “MODULE_LICENSE” -B 27 /usr/src/linux-headers-`uname -r`/include/linux/module.h

• Мы устанавливаем init (загрузка) и exit (выгрузка) как статические функции, которые возвращают целые числа.
• Обратите внимание на использование printk вместо printf . Также параметры printk отличаются от printf . Например, флаг KERN_INFO для объявления приоритета журналирования для конкретной строки указывается без запятой. Ядро разбирается с этими вещами внутри функции printk для экономии памяти стека.
• В конце файла можно вызвать module_init и module_exit и указать функции загрузки и выгрузки. Это даёт возможность произвольного именования функций.

Obj-m += lkm_example.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Если мы запускаем make , он должен успешно скомпилировать наш модуль. Результатом станет файл lkm_example.ko . Если выскакивают какие-то ошибки, проверьте, что кавычки в исходном коде установлены корректно, а не случайно в кодировке UTF-8.

Теперь можно внедрить модуль и проверить его. Для этого запускаем:

Sudo insmod lkm_example.ko
Если всё нормально, то вы ничего не увидите. Функция printk обеспечивает выдачу не в консоль, а в журнал ядра. Для просмотра нужно запустить:

Sudo dmesg
Вы должны увидеть строку “Hello, World!” с меткой времени в начале. Это значит, что наш модуль ядра загрузился и успешно сделал запись в журнал ядра. Мы можем также проверить, что модуль ещё в памяти:

Lsmod | grep “lkm_example”
Для удаления модуля запускаем:

Sudo rmmod lkm_example
Если вы снова запустите dmesg, то увидите в журнале запись “Goodbye, World!”. Можно снова запустить lsmod и убедиться, что модуль выгрузился.

Как видите, эта процедура тестирования слегка утомительна, но её можно автоматизировать, добавив:

Test: sudo dmesg -C sudo insmod lkm_example.ko sudo rmmod lkm_example.ko dmesg
в конце Makefile, а потом запустив:

Make test
для тестирования модуля и проверки выдачи в журнал ядра без необходимости запускать отдельные команды.

Теперь у нас есть полностью функциональный, хотя и абсолютно тривиальный модуль ядра!

Копнём чуть глубже. Хотя модули ядра способны выполнять все виды задач, взаимодействие с приложениями - один из самых распространённых вариантов использования.

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

Вероятно, раньше вы уже имели дело с файлами устройств. Команды с упоминанием /dev/zero , /dev/null и тому подобного взаимодействуют с устройствами “zero” и “null”, которые возвращают ожидаемые значения.

В нашем примере мы возвращаем “Hello, World”. Хотя это не особенно полезная функция для приложений, она всё равно демонстрирует процесс взаимодействия с приложением через файл устройства.

Вот полный листинг:

#include #include #include #include #include MODULE_LICENSE(“GPL”); MODULE_AUTHOR(“Robert W. Oliver II”); MODULE_DESCRIPTION(“A simple example Linux module.”); MODULE_VERSION(“0.01”); #define DEVICE_NAME “lkm_example” #define EXAMPLE_MSG “Hello, World!\n” #define MSG_BUFFER_LEN 15 /* Prototypes for device functions */ static int device_open(struct inode *, struct file *); static int device_release(struct inode *, struct file *); static ssize_t device_read(struct file *, char *, size_t, loff_t *); static ssize_t device_write(struct file *, const char *, size_t, loff_t *); static int major_num; static int device_open_count = 0; static char msg_buffer; static char *msg_ptr; /* This structure points to all of the device functions */ static struct file_operations file_ops = { .read = device_read, .write = device_write, .open = device_open, .release = device_release }; /* When a process reads from our device, this gets called. */ static ssize_t device_read(struct file *flip, char *buffer, size_t len, loff_t *offset) { int bytes_read = 0; /* If we’re at the end, loop back to the beginning */ if (*msg_ptr == 0) { msg_ptr = msg_buffer; } /* Put data in the buffer */ while (len && *msg_ptr) { /* Buffer is in user data, not kernel, so you can’t just reference * with a pointer. The function put_user handles this for us */ put_user(*(msg_ptr++), buffer++); len--; bytes_read++; } return bytes_read; } /* Called when a process tries to write to our device */ static ssize_t device_write(struct file *flip, const char *buffer, size_t len, loff_t *offset) { /* This is a read-only device */ printk(KERN_ALERT “This operation is not supported.\n”); return -EINVAL; } /* Called when a process opens our device */ static int device_open(struct inode *inode, struct file *file) { /* If device is open, return busy */ if (device_open_count) { return -EBUSY; } device_open_count++; try_module_get(THIS_MODULE); return 0; } /* Called when a process closes our device */ static int device_release(struct inode *inode, struct file *file) { /* Decrement the open counter and usage count. Without this, the module would not unload. */ device_open_count--; module_put(THIS_MODULE); return 0; } static int __init lkm_example_init(void) { /* Fill buffer with our message */ strncpy(msg_buffer, EXAMPLE_MSG, MSG_BUFFER_LEN); /* Set the msg_ptr to the buffer */ msg_ptr = msg_buffer; /* Try to register character device */ major_num = register_chrdev(0, “lkm_example”, &file_ops); if (major_num < 0) { printk(KERN_ALERT “Could not register device: %d\n”, major_num); return major_num; } else { printk(KERN_INFO “lkm_example module loaded with device major number %d\n”, major_num); return 0; } } static void __exit lkm_example_exit(void) { /* Remember - we have to clean up after ourselves. Unregister the character device. */ unregister_chrdev(major_num, DEVICE_NAME); printk(KERN_INFO “Goodbye, World!\n”); } /* Register module functions */ module_init(lkm_example_init); module_exit(lkm_example_exit);

Тестирование улучшенного примера

Obj-m += lkm_example.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean test: # We put a - in front of the rmmod command to tell make to ignore # an error in case the module isn’t loaded. -sudo rmmod lkm_example # Clear the kernel log without echo sudo dmesg -C # Insert the module sudo insmod lkm_example.ko # Display the kernel log dmesg
Теперь после запуска make test вы увидите выдачу старшего номера устройства. В нашем примере его автоматически присваивает ядро. Однако этот номер нужен для создания нового устройства.

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

Sudo mknod /dev/lkm_example c MAJOR 0
(в этом примере замените MAJOR значением, полученным в результате выполнения make test или dmesg)

Параметр c в команде mknod говорит mknod, что нам нужно создать файл символьного устройства.

Теперь мы можем получить содержимое с устройства:

Cat /dev/lkm_example
или даже через команду dd:

Dd if=/dev/lkm_example of=test bs=14 count=100
Вы также можете получить доступ к этому файлу из приложений. Это необязательно должны быть скомпилированные приложения -  даже у скриптов Python, Ruby и PHP есть доступ к этим данным.

Когда мы закончили с устройством, удаляем его и выгружаем модуль:

Sudo rm /dev/lkm_example sudo rmmod lkm_example

Заключение

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