Глава 4. Написание вашего первого модуля ядра - LKM, Часть I

Если вы тщательно следовали Главе 1, Настройка рабочего пространства ядра, основные технические предварительные требования, которым вы следовали, уже ыполнены. (Эта глава к тому же упоминает различные инструменты и продукты с открытым исходным кодом; я определённо рекомендую вам просмотреть её ещё разок.) Для вашего удобства мы суммируем здесь некоторые ключевые моменты.

Для борки и применения некого модуля ядра, требуемый вами дистрибутив Linux (или настроенная система), как минимум, нуждается в установке следующих двух компонентов:

Полное дерево исходного кода для этой книги доступно в репозитории GitHub, а код для этой главы расположен в каталоге ch4. Мы определённо ожидаем от вас клонирование следующего:

git clone https://github.com/PacktPublishing/Linux-Kernel-Programming.git
		

Весь код для данной главы расположен в каталоге тёзке chn (где n это номер главы: в данном случае, это ch4/).

В данном разделе мы приступим к погружению в своё понимание ядра. Более конкретно, здесь мы окунаемся в то что представляют собой пространство ядра и пользователя и те основные подсистемы и различные компоненты, которые и составляют само ядро Linux. Эти сведения имеют дело с более высоким уровнем абстракции на данный момент и умышленно оставляются краткими. В материю самого ядра мы окунёмся глубже в Главе 6, Существенные моменты внутреннего устройства ядра - Процессы и Потоки.

Современные микропроцессоры, как минимум, поддерживают два привилегированных уровня. В качестве примеров реального мира, семейство x86[-64] Intel/ AMD поддерживает четыре привилегированных уровня (они носят название уровней кольца), а семейство микропроцессоров ARM (32- битных) поддерживает до семи (ARM именует их режимами исполнения; шесть являются привилегированными и один не привилегированный).

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

Следующий рисунок показывает такую базовую архитектуру:

 

Рисунок 4-1

Основа архитектуры - два привилегированных узла

Далее следуют некоторые подробности об архитектуре системы Linux; продолжайте чтение.

Пространство пользователя для выполнения своей работы зачастую полагается на API (Application Programming Interfaces, Интерфейсы прикладных программ). Библиотека, по существу, некий набор или архив API, позволяющий вам использовать стандартизованные, хорошо написанные, протестированные надлежащим образом интерфейсы (и применять обычные преимущества: не изобретать велосипед, переносимость, стандартизацию и тому подобное). Системы Linux имеют несколько библиотек; в системах корпоративного класса не редко даже сотни. Причём, как вы увидите из них все приложения (исполняемые) пользовательского режима Linux "автоматически связываются" с одной важно и всегда применяемой библиотекой: glibc - GNU standard C library. Однако библиотеки доступны лишь в пользовательском режиме; само ядро не обладает библиотеками (дополнительно об этом в нашей следующей главе).

Примерами библиотечных API выступают хорошо знакомые printf(3) (возвращаем вас к Главе 1, Настройка рабочего пространства ядра, тому разделу страниц руководства, в котором можно обнаружить этот API), scanf(3), strcmp(3), malloc(3) и free(3).

Теперь некий ключевой момент: когда пользователь и ядро являются разными адресными пространствами и пребывают в разных уровнях привилегий, как некий пользовательский процесс способен выполнить доступ к своему ядру? Короткий вариант ответа через системные вызовы. Некий системный вызов (system call) это особенный API, в том плане, что именно он выступает тем единственным допустимым (синхронным) способом для процессов пространства пользователя выполнять доступ к своему ядру. Иными словами, системные вызовы выступают той самой единственной точкой входа для своего пространства ядра. Они обладают возможностью переключения из непривилегированного режима пользователя в привилегированный режим ядра (дополнительно об этом и монолитной архитектуре в Главе 6, Существенные моменты внутреннего устройства ядра - Процессы и Потоки, в разделе Разбираемся с контекстами процессов и прерываний. Примерами системных вызовов могут служить fork(2), execve(2), open(2), read(2), write(2), socket(2), accept(2), chmod(2)) и тому подобные.

	Совет
	Взгляните на все API библиотек и системных вызовов в их страницах руководства в Интернете: - API библиотек, раздел 3 man - API системных вызовов, раздел 2 man

Тут мы подчёркиваем, что в действительности пользовательские приложения и их ядро взаимодействуют исключительно через системные вызовы; именно они выступают таким интерфейсом. В данной книге мы не будем далее погружаться в эти подробности. Если вы дополнительно интересуетесь этими вопросами, будьте добры обратиться к книге Packt Hands-On System Programming with Linux, в особенности к Chapter 1, Linux System Architecture.

Естественно, эта книга сосредотачивается на пространстве самого ядра. На сегодняшний день ядро Linux достаточно большая и сложная бестия. Изнутри оно состоит из нескольких главных подсистем и различных компонентов. Широкий перечень подсистем и компонентов выдаёт следующий список:

Всё это составляет необходимые главные подсистемы ядра; кроме того, мы ещё имеем следующее:

	Совет
	Вернитесь к Сборка ядра Linux 5.4 из исходного кода - Часть I, разделу Краткий тур по дереву исходного кода ядра, который предоставляет схему дерева исходного кода ядра, относящегося ко всем основным подсистемам и прочим компонентам.

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

 

Рисунок 4-2

Пространство ядра - главные подсистемы и блоки

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

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

Теперь, когда мы обладаем базовым пониманием пространств пользователя и ядра, давайте двинемся дальше и начнём своё путешествие в инфраструктуру LKM.

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

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

Хотя это может показаться простым, в действительности это большой объём работы - всякое изменение в том коде, который мы написали, каким бы незначительным оно не было, потребует повторной сборки всего образа ядра и последующей перезагрузки вашей системы для его проверки. Должен иметься более ясный чистый и простой способ; и он действительно имеется - инфраструктура LKM!

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

Сам исходный код модуля ядра обычно состоит из одного или более исходный файлов C, файлов заголовков и некого Makefile, затем собирается (естественно, посредством make(1)) в некий модуль ядра. Такой модуль ядра сам по себе это всего лишь некий файл двоичного объекта, а не исполняемый двоичный файл. В Linux 2.4 и более ранних версиях, название файла такого модуля ядра обладало суффиксом .o; в современном Linux 2.6 и старше, вместо этого он обладает суффиксом .ko (kernel object). После его построения вы можете вставить этот .ko - модуль ядра - в само действующее ядро времени исполнения, эффективно превращая его в часть своего ядра.

Замечание

Обратите внимание на то, что через инфраструктуру LKM могут предоставляться не все функциональные возможности ядра. Некоторая центральная функциональность, например, такая как код планировщика ЦПУ, управление памятью сигналами, таймер, пути кода управления прерываниями и тому подобное, могут разрабатываться исключительно внутри самого ядра. Аналогично, модулю ядра допускается выполнять доступ лишь к некому подмножеству всего API полного ядра; дополнительно об этом чуть позднее.

Вы можете задать вопрос: как я выполняю вставку некого объекта в своё ядро? Давайте оставим это простым - ответ такой: через insmod(8). На данный момент давайте опустим подробности (они будут пояснены в последующем разделе Исполнение модуля ядра). Приводимая ниже схема предоставляет некий обзор первой сборки и последующей вставки какого- то модуля ядра в память ядра:

 

Рисунок 4-3

Сборка и последующая вставка модуля ядра в память ядра

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

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

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

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

На самом деле, объект модуля ядра не является чем- то совсем не знакомым для нас. В Главе 3, Сборка ядра Linux 5.4 из исходного кода - Часть II мы собирали модули ядра как часть процесса сборки своего ядра и устанавливали их.

Вспомните, что эти модули ядра являются частью исходного кода ядра и настраивались как модули через выбор M в приглашении на ввод настроек меню ядра с тремя состояниями. Они устанавливались в каталоги под /lib/modules/$(uname -r)/. Поэтому, чтобы увидеть слегка больше относящегося к установленным модулям ядра под нашим исполняемым в настоящее время гостевым ядром Ubuntu 18.04.3 LTS, мы можем сделать следующее:

$ lsb_release -a 2>/dev/null |grep Description
Description:    Ubuntu 18.04.3 LTS
$ uname -r
5.0.0-36-generic
$ find /lib/modules/$(uname -r)/ -name "*.ko" | wc -l
5359 
		

Ладно, парни из Canonical и ещё откуда- то там плотно подошли к делу. Более пяти тысяч модулей ядра... Только задумайтесь об этом: дистрибуторы не могут знать на будущее в точности какое именно периферийное оборудование некий пользователь в конце концов применяет (в особенности в обычных компьютерах, таких как системы на основе x86). Модули ядра служат удобным средством для поддержки гигантских количеств оборудования без безумного раздувания самого файла образа ядра (к примеру, bzImage или zImage).

Все установленные модули ядра для нашей системы Ubuntu Linux обитают внутри каталога /lib/modules/$(uname -r)/kernel, что можно обнаружить тут:

$ ls /lib/modules/5.0.0-36-generic/kernel/
arch/  block/  crypto/  drivers/  fs/  kernel/  lib/  mm/  net/  samples/  sound/  spl/  ubuntu/  virt/  zfs/
$ ls /lib/modules/5.4.0-llkd01/kernel/
arch/  crypto/  drivers/  fs/  net/  sound/
$
		

Здесь, глядя на верхний уровень каталога kernel/ под /lib/modules/$(uname -r) для своего ядра дистро (Ubuntu 18.04.3 LTS исполняет ядро 5.0.0-36-generic), мы видим, что имеется большое число вложенных каталогов и в буквальном смысле в них упаковано несколько тысяч модулей ядра. напротив, для собранного нами ядра (за подробностями обратитесь к Главе 2, Сборка ядра Linux 5.4 из исходного кода - Часть I и Главе 3, Сборка ядра Linux 5.4 из исходного кода - Часть II) их имеется гораздо меньше. Из нашего обсуждения в Главе 2, Сборка ядра Linux 5.4 из исходного кода - Часть I, вы вспомните, что преднамеренно воспользовались целью localmodconfig чтобы сохранить свою сборку небольшой и быстрой. Таким образом, в нашем индивидуальном ядре 5.4.0 имеется всего лишь 60 с небольшим собранных для него модулей.

Одна из отраслей, в которой наблюдается довольно интенсивное применение модулей ядра это драйверы устройств. В качестве образца, давайте взглянем на драйвер сетевого устройства, который спроектирован в виде модуля ядра. Вы можете отыскать какое- то их число (также и совместно со знаменитыми иенами производителей!) в папке своего дистро ядра kernel/drivers/net/ethernet:

 

Рисунок 4-4

Пространство ядра - главные подсистемы и блоки

Во многих ноутбуках на основе Intel распространённым является адаптер ethernet NIC (Network Interface Card, платы сетевого интерфейса) Intel 1GbE. Управляющий ею драйвер сетевого устройства носит название драйвера e1000. Наш гость x86-64 Ubuntu 18.04.3 (запущенный в ноутбуке хоста x86-64) показывает что он и в самом деле применяет этот драйвер:

$ lsmod | grep e1000
e1000                 139264  0
		

В скором времени мы более детально изучим утилиту lsmod(8) ('list modules'). Что нам более важно, мы можем обнаружить, что это модуль ядр! Как относительно того чтобы получить некие дополнительные сведения по этому конкретному модулю ядра? Это достаточно просто осуществляется при помощи утилиты modinfo(8) (для лучшей читаемости мы усекли здесь её подробный вывод):

$ ls -l /lib/modules/5.0.0-36-generic/kernel/drivers/net/ethernet/intel/e1000
total 220
-rw-r--r-- 1 root root 221729 Nov 12 16:16 e1000.ko
$ modinfo /lib/modules/5.0.0-36-generic/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
filename:       /lib/modules/5.0.0-36-generic/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
version:        7.3.21-k8-NAPI
license:        GPL v2
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, 
srcversion:     C521B82214E3F5A010A9383
alias:          pci:v00008086d00002E6Esv*sd*bc*sc*i*
[...]
name:           e1000
vermagic:       5.0.0-36-generic SMP mod_unload 
[...]
parm:           copybreak:Maximum size of packet that is copied to a new 
                buffer on receive (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)
		

Эта утилита modinfo(8) позволяет нам прицепиться к двоичному образу модуля ядра и выделить некоторые относящиеся к нему подробности; дополнительные сведения относительно применения modinfo в нашем следующем разделе.

Совет

Другим способом получения полезных сведений в вашей системе, включая сведения относительно загруженных в настоящее время модулей ядра является работа через утилиту systool(1). Для некого установленного модуля ядра (подробнее об установке модуля ядра далее в нашей следующей главе в разделе Автоматически загружаемые модули при запуске системы) выполнение systool -m <module-name> -v раскроет сведения о нём. Относительно подробностей применения systool(1) загляните в его страницу руководства.

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

Итак, раз вы желаете изучить как писать драйвер устройства Linux, файловую систему или некий межсетевой экран, вам надлежит изучить ка писать некий модуль ядра, тем самым применяя мощную инфраструктуру LKM ядра. Это именно то чем мы и займёмся далее.

При представлении нового языка или темы программирования стало широко распространённой традицией вычислительного программирования имитировать оригинальную программу K&R Hello, world в качестве самого первого фрагмента кода. Я счастлив следовать этой почитаемой традиции и представить мощную инфраструктуру LKM. В этом разделе вы изучите основные этапы кодирования образца LKM. Мы подробно поясним этот код.

Без всякой дополнительной суеты вот некий простой код C Hello, world, реализуемый по канонам инфраструктуры LKM ядра Linux:

	Замечание
	По причинам удобства чтения и стеснённости пространства здесь отображается лишь части нашего исходного кода. Чтобы просмотреть исходный код целиком, собрать его и исполнить, весь исходный код для этой книги доступен в её репозитории GiytHub. Мы определённо ожидаем что вы клонируете его: git clone https://github.com/PacktPublishing/Linux-Kernel-Programming.git.

// ch4/helloworld_lkm/hellowworld_lkm.c
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>

MODULE_AUTHOR("<insert your name here>");
MODULE_DESCRIPTION("LLKD book:ch4/helloworld_lkm: hello, world, our first LKM");
MODULE_LICENSE("Dual MIT/GPL");
MODULE_VERSION("0.1");

static int __init helloworld_lkm_init(void)
{
    printk(KERN_INFO "Hello, world\n");
    return 0;     /* success */
}

static void __exit helloworld_lkm_exit(void)
{
    printk(KERN_INFO "Goodbye, world\n");
}

module_init(helloworld_lkm_init);
module_exit(helloworld_lkm_exit);
 	   

Вы можете испробовать этот образец модуля ядра Hello, world прямо сейчас! Просто выполните cd в правильный каталог исходного кода, как показано тут и воспользуйтесь нашим вспомогательным сценарием lkm для его сборки и запуска:

$ cd <...>/ch4/helloworld_lkm
$ ../../lkm helloworld_lkm
Version info:
Distro:     Ubuntu 18.04.3 LTS
Kernel: 5.0.0-36-generic
[...]
dmesg
[ 5399.230367] Hello, world
$
		

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

Последующие подразделы достаточно хорошо поясняют каждую строку нашего предыдущего кода C Hello, world. Помните, что несмотря на то, что данная программа кажется очень маленькой и тривиальной, имеется много чего относящегося к ней и вокруг инфраструктуры LKM для понимания. Вся оставшаяся часть этой главы сосредоточена на этом и вдаётся в мельчайшие подробности. Я настоятельно рекомендую вам потратить своё время на то чтобы вначале прочесть и усвоить все эти основополагающие моменты. Это безмерно поможет вам в дальнейшем, возможно, в ситуациях сложных для отладки.

Заголовки ядра

Для нескольких файлов заголовков мы пользуемся #include. В отличии от разработки приложений 'C' в пространстве пользователя, это заголовки ядра (как мы уже упоминали в своём разделе Технические требования). Из Главы 3, Сборка ядра Linux 5.4 из исходного кода - Часть II вспомните, что модули ядра устанавливались в особенной ветви, доступной на запись root. Давайте проверим её снова (здесь мы выполняем работу из своей гостевой ВМ Ubuntu x86_64 с ядром дистро 5.0.0-36-generic):

$ ls -l /lib/modules/$(uname -r)/
total 5552
lrwxrwxrwx  1 root root      39 Nov 12 16:16 build -> /usr/src/linux-headers-5.0.0-36-generic/
drwxr-xr-x  2 root root    4096 Nov 28 08:49 initrd/
[...] 
		

Обратите внимание на символьную или программную ссылку с названием build. Она указывает на место необходимых заголовков ядра в нашей системе. В нашем предыдущем коде мы пребывали под /usr/src/linux-headers-5.0.0-36-generic/! Как вы увидите, мы предоставим эти сведения в Makefile, применяемый для сборки своего модуля ядра. (Кроме того, некоторые системы обладают аналогичной программной ссылкой с названием source.)

Замечание

Пакет kernel-headers или linux-headers распаковывает некое ограниченное дерево исходного кода ядра, обычно в /usr/src/.... Этот код, тем не менее, не полон вследствии применения нами фразы limited дерева исходного кода. Это обусловлено тем, что полное дерево исходного кода не требуется для целей сборки модулей - то что выделяется из пакетов, так это только необходимые модулям компоненты (сами заголовки, соответствующие Makefiles и тому подобное).

Самой первой строкой в нашем модуле ядра Hello, world является #include <linux/init.h>.

Наш компилятор выполняет её разрешение отыскивая упомянутый ранее файл заголовка ядра в /lib/modules/$(uname -r)/build/include/. Таким образом, посредством следующей программной ссылки build мы можем обнаружить, что он подхватывает этот файл заголовка:

$ ls -l /usr/src/linux-headers-5.0.0-36-generic/include/linux/init.h
-rw-r--r-- 1 root root 9704 Mar  4  2019 /usr/src/linux-headers-5.0.0-36-generic/include/linux/init.h
		

Тому же самому следуют и прочие включённые в исходный код модуля ядра заголовки ядра.

Макросы модуля

Далее у нас имеется несколько модулей макросов из MODULE_FOO(); большинство из них достаточно понятны интуитивно:

В отсутствии самого исходного кода, как эти сведения будут предоставлены конечному пользователю (или потребителю)? Ах, да, наша утилита modinfo(8) выполняет именно это! Эти макросы и их сведения могут показаться тривиальными, однако они важны в проектах и продуктах. На эти сведения, к примеру, полагается производитель, устанавливающий лицензии (открытого исходного кода), под которыми исполняется данный код, применяя вывод grep для modinfo во всех установленных модулях ядра.

Точки входа и выхода

Никогда не забывайте, что помимо всего прочего, модули ядра являются выполняющимся с полномочиями ядра кодом ядра. Это не приложение, а следовательно нет точки входа, аналогичной знакомой нам функции main() (которую мы хорошо знаем и любим). Естественно, напрашивается вопрос: что выступает точками входа и выхода нашего модуля ядра? Обратите внимание на следующие строки внизу нашего образца модуля ядра:

module_init(helloworld_lkm_init);
module_exit(helloworld_lkm_exit);
 	   

Такой код module_[init|exit]() это макрос, определяющий, соответственно, необходимые точки входа и выхода. Значением параметра для каждого выступает некая ссылка на функцию. В современных компиляторах C мы можем просто определять значение названия соответствующей функции. Таким образом, в нашем коде применимо следующее:

Вы можете просто представлять себе эти точки входа и выхода просто как пару конструктор/ деструктор для некого модуля ядра. Технически говоря, это, естественно, не наш случай, поскольку это не код объектно- ориентированного C++, это простой C. Тем не менее, это полезная аналогия.

Возвращаемые значения

Обратите внимание на следующие внешние признаки функций init и exit:

static int  __init <modulename>_init(void);
static void __exit <modulename>_exit(void);
 	   

В качестве достойной практики кодирования мы пользуемся форматом именования функций в виде <modulename>_[init|exit](), где <modulename> заменяется значением названия этого модуля ядра. Вы осознаете, что такое соглашение именования это всего лишь соглашение и, с технической точки зрения оно не обязательно, однако оно интуитивно понятно, а потому полезно. Очевидно, что ни одна из подпрограмм не получает никаких параметров.

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

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

Соглашение возврата 0/-E

Функция init соответствующего модуля ядра служит для возврата некого значения с типом int; это ключевой момент. Само ядро Linux вовлечено в стиль или соглашение, если хотите, в отношении возвращаемых из него значений (имеется в виду, из самого пространства ядра в соответствующее пространство пользователя процесса). Инфраструктура LKM следует тому, что в просторечии носит название соглашения 0/-E:

Быстрый пример того как выполнять возврат из функции init модуля ядра поможет прояснить это: допустим, функция init нашего модуля ядра пытается динамически выделить некую память ядра (подробности этого API kmalloc() и всё прочее, естественно, будут рассмотрены в последующих главах; игнорируйте, пожалуйста, их пока). Далее мы можем кодировать это следующим образом:

[...]
ptr = kmalloc(87, GFP_KERNEL);
if (!ptr) {
    pr_warning("%s:%s:%d: kmalloc failed!\n", __FILE__, __func__, __LINE__);
    return -ENOMEM;
}
[...]
return 0;   /* success */
		

Когда выделение памяти завершено отказом (что очень маловероятно, однако - эй, это происходит!), мы делаем следующее:

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

О подпрограмме уборки особенно и нечего сказать. Она не получает никаких параметров и ничего не возвращает (void). Её задание состоит в выполнении любых необходимых чисток прежде чем этот модуль ядра выгрузится из памяти ядра.

Совет

Не включая макро module_exit() в свой модуль ядра, вы превращаете в невозможную вообще его выгрузку (хотя конечно остаются останов системы или перезагузка). Занимательно... (Я предлагаю вам испытать это в качестве маленького упражнения!) Естественно: нет ничего проще: такое поведение гарантировано предотвращает выгрузку только когда ваше ядро собрано с флагом CONFIG_MODULE_FORCE_UNLOAD, установленным в Disabled (по умолчанию).

Макросы ERR_PTR и PTR_ERR

После обсуждения возврата значений вы теперь понимаете что соответствующая процедура init своего модуля ядра обязана возвращать некое целое. Что если вы желаете вернуть вместо этого некий указатель? На помощь нам приходит встроенная функция ERR_PTR(), позволяя возвращать некий указатель замаскированный под целое число, просто приводя его значение к void *. В действительности он поступает лучше: вы можете проверить наличие некоторой ошибки при помощи встроенной функции IS_ERR() (которая на самом деле всего выводит бедет ли полученное значение пребывать в диапазоне [-1 до -4095]), кодирует некое отрицательное значение ошибки в указатель посредством встроенной функции ERR_PTR() и выполняет выборку этого значения по такому указателю при помощи обратной процедуры PTR_ERR().

В качестве простого примера рассмотрим представленный здесь код вызывающей стороны. На этот раз у нас имеется (образец) функции myfunc(), возвращающей некий указатель (на структуру с названием mystruct) а не некое целое:

struct mystruct * myfunc(void)
{
    struct mystruct *mys = NULL;
    mys = kzalloc(sizeof(struct mystruct), GFP_KERNEL);
    if (!mys)
        return ERR_PTR(-ENOMEM);
    [...]
    return mys;
}
		

[...]
gmys = myfunc();
if (IS_ERR(gmys)) {
    pr_warn("%s: myfunc alloc failed, aborting...\n", OURMODNAME);
    stat = PTR_ERR(gmys); /* sets 'stat' to the value -ENOMEM */
    goto out_fail_1;
}
[...]
return stat;
out_fail_1:
    return stat;
}