eduplan-cpp-eltex/lessons/D6_kernel.md

# D6, часть 1. Ядро и embedded обзорно (урок)

Уровень этого урока — «уверенно отвечать словами на собеседовании», а не «написать драйвер
с нуля». Идём от границы user space/kernel space к модулю, от модуля к драйверу символьного
устройства, от драйвера к железу (device tree, cross-compile, загрузка платы). Опорные
источники для самостоятельного углубления: docs.kernel.org, The Linux Kernel Module
Programming Guide (LKMPG), `man 2`/`man 3`/`man 7` (системные вызовы, библиотечные функции,
конвенции ядра).

## 1. User space vs kernel space и системный вызов как переход границы

Процессор x86 поддерживает уровни привилегий (кольца защиты): **кольцо 0** — режим ядра,
полный доступ к железу и памяти; **кольцо 3** — режим пользователя, обычные программы, без
прямого доступа к физической памяти чужих процессов или портам ввода-вывода. Ядро работает в
кольце 0, все обычные процессы — в кольце 3. Разделение существует ради защиты и стабильности:
если бы любая программа могла напрямую писать в память другого процесса или в регистры
диска, ошибка или злой умысел в одной программе обрушивали бы всю систему.

Чтобы попросить ядро что-то сделать (открыть файл, выделить память, создать процесс),
пользовательская программа не может просто вызвать функцию ядра — она делает **системный
вызов**: специальную инструкцию процессора, которая переключает CPU в привилегированный режим
и передаёт управление фиксированному обработчику в ядре, а после выполнения запроса управление
возвращается программе обратно в непривилегированном режиме. На x86-64 эту инструкцию зовут
**`syscall`**, на ARM — **`svc`** (supervisor call). Оба случая — не обычный вызов функции
(`call`), а специальная инструкция именно потому, что она обязана сменить уровень привилегий
процессора, а не просто передать управление по адресу.

**Факты для карточек**
- base | В каком кольце защиты x86 работает ядро Linux? — в кольце 0 (пользовательские процессы — в кольце 3)
- base | Какая инструкция делает системный вызов на x86-64? — `syscall` (на ARM — `svc`)
- core | Почему системный вызов — отдельная инструкция процессора, а не обычный `call`? — обычный `call` не меняет уровень привилегий CPU, а переход в кольцо 0 требует именно смены режима процессора

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

## 2. Модуль ядра vs встроенный в ядро

Функциональность можно либо **встроить в ядро** на этапе сборки (код компилируется прямо в
образ ядра, доступен сразу при загрузке, но требует пересборки и перезагрузки при любом
изменении), либо оформить как **загружаемый модуль ядра** (`.ko`-файл, подключается и
отключается в работающей системе без перезагрузки). Встроенным делают то, что нужно с самого
первого момента загрузки (например, драйвер корневой файловой системы); модулем — то, что
может понадобиться позже или не понадобиться вовсе (драйвер конкретного периферийного
устройства), чтобы не раздувать образ ядра и не грузить лишний код.

Инструменты управления модулями:
- **`insmod <path.ko>`** — загружает модуль по прямому пути к файлу, без разрешения
  зависимостей от других модулей.
- **`rmmod <name>`** — выгружает модуль по имени (если счётчик использования равен нулю).
- **`modprobe <name>`** — загружает модуль по имени, сам находит файл в
  `/lib/modules/$(uname -r)/` и подгружает зависимости по карте `modules.dep` (строится
  утилитой `depmod`) — на практике используется чаще `insmod`, именно из-за автоматических
  зависимостей.
- **`lsmod`** — список загруженных сейчас модулей (по сути читает `/proc/modules`), с
  размером и счётчиком использования.
- **`modinfo <name|path>`** — метаданные модуля (лицензия, описание, параметры, зависимости)
  без его загрузки в ядро.

**Факты для карточек**
- base | Чем `insmod` отличается от `modprobe`? — `insmod` грузит модуль по прямому пути без разрешения зависимостей, `modprobe` находит модуль по имени и сам подгружает зависимости
- base | Какая команда показывает метаданные модуля, не загружая его? — `modinfo`
- core | Откуда `modprobe` берёт карту зависимостей модулей? — из файла `modules.dep`, который строит утилита `depmod`

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

## 3. Структура простейшего модуля

```c
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

static int __init hello_init(void)
{
    printk(KERN_INFO "hello: module loaded\n");
    return 0;                 // 0 — успех; ненулевой код отменяет загрузку модуля
}

static void __exit hello_exit(void)
{
    printk(KERN_INFO "hello: module unloaded\n");
}

module_init(hello_init);      // вызывается ядром при insmod/modprobe
module_exit(hello_exit);      // вызывается ядром при rmmod
MODULE_LICENSE("GPL");
```

`module_init`/`module_exit` — не обычные вызовы функций, а макросы, которые регистрируют
функции как точки входа/выхода: сам код внутри них ядро вызывает автоматически в момент
`insmod`/`rmmod`, программист их напрямую не зовёт. `MODULE_LICENSE("GPL")` обязателен: без
него или с иной лицензией ядро помечает себя как **tainted** (загрязнённое) и закрывает
модулю доступ к символам, экспортированным только для GPL-кода (`EXPORT_SYMBOL_GPL`).

`printk` — это `printf` уровня ядра, пишет не в консоль процесса, а в кольцевой буфер ядра.
Первым аргументом обычно идёт уровень важности — восемь уровней от `KERN_EMERG` (0,
критично) до `KERN_DEBUG` (7, отладочная информация); сообщения с уровнем выше порога
консоли попадают только в буфер, но не печатаются на экран сразу. Прочитать буфер целиком —
команда **`dmesg`**.

**Факты для карточек**
- base | Какой макрос ядра — аналог `printf`? — `printk`
- base | Команда для чтения буфера сообщений ядра? — `dmesg`
- core | Сколько уровней важности у `printk` и какие крайние? — 8 уровней, от `KERN_EMERG` (0) до `KERN_DEBUG` (7)
- core | Что произойдёт с модулем без `MODULE_LICENSE("GPL")`? — ядро станет tainted и закроет модулю доступ к символам `EXPORT_SYMBOL_GPL`
- core | Кто вызывает функции, зарегистрированные `module_init`/`module_exit`? — ядро автоматически, при `insmod`/`modprobe` и `rmmod` соответственно, а не сам программист

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

## 4. Параметры модуля: `module_param`

```c
static int count = 1;
module_param(count, int, S_IRUGO);   // третий аргумент — права доступа в sysfs
```

`module_param(имя, тип, права)` (заголовок `<linux/moduleparam.h>`) делает переменную
настраиваемой при загрузке модуля — значение можно передать прямо в `insmod modname.ko
count=5`. Третий аргумент — режим доступа файла в sysfs: `0` означает, что параметр доступен
только при загрузке и не публикуется отдельным файлом, ненулевое значение (например
`S_IRUGO` — чтение всем) создаёт файл `/sys/module/<имя_модуля>/parameters/<count>`, из
которого параметр можно прочитать (а при подходящих правах — и переписать) уже после загрузки.

**Факты для карточек**
- base | Как передать параметр модулю при загрузке? — `insmod modname.ko имя_параметра=значение`
- core | Что означает третий аргумент `module_param`, если он ненулевой? — параметр публикуется файлом в `/sys/module/<имя>/parameters/<имя>` с заданными правами доступа

Почему дальше: файл параметра в sysfs — частный случай общего механизма, которым ядро вообще
разговаривает с пользовательским пространством через файловую систему, — `/proc` и `/sys`.

## 5. `/proc` и `/sys` как интерфейс к ядру

**`/proc`** (procfs) — виртуальная файловая система, изначально созданная для информации о
процессах (`/proc/<pid>/...`), позже расширенная общей информацией о ядре (`/proc/cpuinfo`,
`/proc/meminfo`, `/proc/modules`); файлы внутри часто содержат несколько значений свободным
текстом. **`/sys`** (sysfs, с ядра 2.6) — более новый и структурированный интерфейс,
отражающий модель устройств и драйверов ядра (шины, устройства, классы), с соглашением «один
файл — одно значение», что упрощает и чтение скриптами, и программную запись настроек. Оба
это не диски, а генерируются ядром на лету при каждом обращении — `cat /proc/meminfo`
формирует ответ в момент чтения, а не читает файл с диска.

**Факты для карточек**
- base | Чем отличается соглашение о содержимом файлов `/sys` от `/proc`? — в `/sys` одно значение на файл, в `/proc` файл может содержать несколько значений свободным текстом
- core | Откуда `cat /proc/meminfo` берёт данные? — ядро формирует ответ на лету в момент чтения, это не файл на диске

Почему дальше: `/proc` и `/sys` — интерфейсы общего назначения; когда нужно управлять
конкретным устройством операциями `open`/`read`/`write`, пишут символьный драйвер.

## 6. Символьный драйвер: `file_operations`, major/minor, барьер user/kernel

Драйвер символьного устройства регистрирует набор функций-обработчиков в структуре
`struct file_operations` — как минимум `.open`, `.read`, `.write`, `.release` (плюс,
например, `.unlocked_ioctl`); ядро вызывает нужный обработчик, когда пользовательский процесс
делает соответствующий системный вызов над файлом устройства в `/dev`. Регистрация —
`register_chrdev(major, name, &fops)`: если `major` передан как `0`, ядро само подбирает
свободный старший номер.

Устройство идентифицируется парой **major:minor**: **major** (старший номер) определяет
драйвер, обслуживающий устройство, **minor** (младший) — конкретный экземпляр внутри этого
драйвера (например, второй последовательный порт того же типа). `dev_t` в современном ядре —
32-битное число: 12 бит под major (до 4095) и 20 бит под minor (до 1 048 575).

Внутри `.read`/`.write` драйвер **не может напрямую разыменовать указатель, пришедший из
пользовательского пространства** — это чужое адресное пространство, страница может быть не
загружена в память или указатель вообще некорректен, а прямое разыменование либо уронит
ядро (kernel oops), либо (на CPU с SMAP/SMEP) вызовет аппаратный запрет. Вместо этого
обязательны **`copy_to_user`**/**`copy_from_user`** — они безопасно копируют данные через
границу, сами обрабатывают отсутствующую страницу и возвращают число байт, которые
**не** удалось скопировать (0 — полный успех).

**Ловушки**
- Разыменовать пользовательский указатель напрямую в `.read`/`.write` → крах ядра (oops) или
  аппаратный запрет на SMAP/SMEP-системах → видно как немедленный крэш при обращении к
  устройству, а не как «иногда неверные данные».
- Забыть проверить возвращаемое значение `copy_to_user`/`copy_from_user` → часть данных не
  скопирована, а код считает операцию успешной → приложение получает частично мусорный буфер
  без явной ошибки.

**Факты для карточек**
- base | Какие 4 обработчика минимально нужны в `file_operations` символьного драйвера? — `.open`, `.read`, `.write`, `.release`
- core | Что означают major и minor номера устройства? — major определяет драйвер, minor — конкретный экземпляр устройства внутри этого драйвера
- core | Сколько бит под major и minor в `dev_t`? — 12 бит major, 20 бит minor (32-битное число целиком)
- core | Почему в драйвере нельзя напрямую разыменовать указатель из user space? — это чужое адресное пространство, страница может быть не загружена или указатель некорректен; прямое разыменование роняет ядро или блокируется SMAP/SMEP

Почему дальше: `read`/`write` подходят для потока байт, но не для команд, которые не
укладываются в чтение/запись (настроить режим устройства, запросить статус) — для этого есть
`ioctl`.

## 7. `ioctl`: команды, которые не являются чтением или записью

`ioctl` — обработчик `.unlocked_ioctl` в `file_operations`, принимающий числовой код команды
и один аргумент (`unsigned long`, часто указатель на структуру в user space). Используется,
когда операция над устройством не укладывается в модель «поток байт» — например, «сообщи
текущую скорость порта» или «переведи устройство в другой режим». Коды команд собирают
макросами **`_IO`**, **`_IOR`**, **`_IOW`**, **`_IOWR`** (кодируют направление передачи данных,
«магическое число» драйвера и номер команды) — это соглашение снижает риск, что два разных
драйвера случайно используют одинаковый числовой код команды.

**Факты для карточек**
- base | В какой функции `file_operations` реализуется `ioctl`? — `.unlocked_ioctl`
- core | Зачем коды ioctl-команд собирают через `_IO`/`_IOR`/`_IOW`/`_IOWR`, а не пишут произвольным числом? — макросы кодируют направление передачи, магическое число драйвера и номер команды, снижая риск коллизии кодов между разными драйверами

Почему дальше: и `file_operations`, и `ioctl` работают с уже существующим, известным
устройством — а откуда ядро вообще узнаёт, какое железо есть на конкретной плате, особенно в
embedded, где плат много и они разные?

## 8. Device tree: описание железа без хардкода

**Device tree** — текстовое описание аппаратной конфигурации платы (`.dts`, компилируется
утилитой `dtc` в бинарный `.dtb`): адреса регистров периферии, линии прерываний, доступные
шины, строки `compatible`, по которым ядро сопоставляет узел дерева с подходящим драйвером.
Загрузчик передаёт `.dtb` ядру вместе с образом ядра при старте.

Смысл — один и тот же бинарник ядра должен уметь работать на разных платах с разной
периферией и разными адресами регистров без перекомпиляции под каждую плату: без device tree
адреса и конфигурация железа были бы зашиты прямо в код ядра (так называемые board files),
и под каждую новую плату требовалась бы правка и пересборка самого ядра. Device tree выносит
это описание из кода в данные, которые загрузчик просто подкладывает рядом с ядром.

**Факты для карточек**
- base | Во что компилируется `.dts` и какой утилитой? — в бинарный `.dtb`, утилитой `dtc`
- core | Зачем device tree вообще нужен, если можно было бы прописать адреса регистров прямо в коде драйвера? — один и тот же бинарник ядра работает на разных платах без пересборки под каждую; хардкод адресов требовал бы правки и компиляции ядра под каждую конкретную плату

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

## 9. Cross-compile: тулчейн под целевую архитектуру

Сборка ведётся на машине разработчика (обычно x86-64), а результат должен исполняться на
целевом процессоре платы (например, ARM) — обычный компилятор хоста генерирует машинный код
под архитектуру хоста, целевая плата такой код исполнить не сможет. Нужен **кросс-компилятор**
— тулчейн, генерирующий код именно под целевую архитектуру: например `arm-linux-gnueabihf-gcc`.

- **`CROSS_COMPILE`** — переменная окружения/аргумент сборки (используется, например, в
  Makefile ядра и Buildroot), задающая префикс имени инструментов тулчейна
  (`CROSS_COMPILE=arm-linux-gnueabihf-`), чтобы вызывался `arm-linux-gnueabihf-gcc`, а не
  системный `gcc`.
- **`-march`** — флаг компилятора, задающий конкретный набор инструкций целевого процессора
  (например `-march=armv7-a`); несовпадение с реальным железом даёт крах «illegal
  instruction» на плате или отказ собраться, если код использует расширения, которых у
  целевого процессора нет.
- **Статическая сборка** — линковка всех библиотек прямо в бинарник вместо динамических
  `.so`; в embedded это снимает риск несовпадения версии библиотек (например, glibc) в
  минимальном корневом ФС платы с версией, под которую собирался бинарник, ценой большего
  размера самого файла.

**Факты для карточек**
- base | Что задаёт переменная `CROSS_COMPILE`? — префикс имени инструментов тулчейна (например `arm-linux-gnueabihf-`)
- core | Что произойдёт при запуске бинарника, собранного с неверным `-march`, на реальной плате? — крах «illegal instruction» (процессор не поддерживает часть использованных инструкций) или отказ сборки
- core | Какую проблему в embedded снимает статическая линковка? — несовпадение версии динамических библиотек (например glibc) на целевой плате с версией сборки

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

## 10. Загрузка платы: u-boot → ядро+dtb → initramfs → init

Типичная последовательность:
1. Boot ROM процессора (зашит в кристалл, неизменяем) загружает первый этап загрузчика.
2. **U-Boot** — распространённый загрузчик embedded-плат — инициализирует минимально
   необходимое железо (память, консоль) и находит образ ядра и `.dtb` (раздел 8) на носителе.
3. U-Boot загружает **ядро** и **`.dtb`** в память и передаёт управление точке входа ядра.
4. Ядро инициализируется и монтирует **initramfs** — временную корневую файловую систему,
   целиком находящуюся в оперативной памяти, — и запускает из неё `/init`.
5. `/init` в initramfs делает раннюю настройку (загружает нужные модули, находит настоящий
   диск), затем переключается на настоящую корневую файловую систему (`pivot_root`/
   `switch_root`) и запускает уже настоящий **init** (PID 1 — например `systemd` или
   BusyBox init) на постоянном разделе.

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

**Факты для карточек**
- base | В каком порядке идёт цепочка загрузки платы? — Boot ROM → U-Boot → ядро+dtb → initramfs → переключение на настоящий rootfs → init (PID 1)
- core | Зачем нужен initramfs, если ядро уже загружено и работает? — ядру для монтирования настоящего диска может понадобиться драйвер, который сам является модулем и ещё не загружен; initramfs даёт минимальную среду в памяти, чтобы его подгрузить перед переходом на постоянный rootfs

Почему дальше: после того как система загрузилась, embedded-разработчик работает с реальным
железом напрямую через память — а компилятор по умолчанию считает, что содержимое памяти
меняется только его собственным кодом. Разберём, что с этим не так.

## 11. `volatile`, `mmap` регистров и барьеры памяти

Обычная оптимизация компилятора — закэшировать значение переменной в регистре процессора и не
перечитывать его из памяти повторно, если по коду программы оно «не могло измениться».
Регистр памяти-отображённого устройства (MMIO) может измениться сам, независимо от кода
программы (например, статус-регистр меняется самим железом) — без `volatile` компилятор
законно уберёт «повторное» чтение как избыточное, и драйвер будет вечно видеть устаревшее
значение. `volatile` заставляет компилятор реально выполнять каждое обращение к памяти по
этому адресу, не кэшируя и не убирая «дублирующиеся» чтения/записи.

Важная ловушка: `volatile` **не даёт атомарности и не расставляет барьеры памяти** — он
касается только компилятора и только одной переменной, а не порядка операций между
несколькими адресами и не защищает от гонки между несколькими ядрами процессора (для этого в
пользовательском C++ есть `std::atomic`, раздел про многопоточность).

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

**Барьеры памяти** (`mb()`, `rmb()`, `wmb()`) принудительно фиксируют порядок операций чтения
и записи в памяти, как его видит железо — нужны потому, что и компилятор, и сам процессор
вправе переставлять инструкции местами, если это не меняет результат с точки зрения
однопоточной программы, а DMA-контроллер или другое устройство читает память независимо от
этого порядка. Типичный случай: драйвер записывает данные в дескриптор DMA-кольца
(`tasks/03_ring`, задача этого набора про кольцевой буфер — та же структура head/tail лежит
в основе DMA-колец), а затем «звонит в дверной звонок» — пишет в регистр, запускающий
устройство; без `wmb()` между этими двумя записями устройство может увидеть сигнал запуска
раньше, чем реально записанные данные дескриптора, и прочитать старое содержимое.

**Ловушки**
- Забыть `volatile` на указателе на регистр устройства → компилятор кэширует значение в
  регистре CPU и не видит изменений железа → драйвер «зависает», читая одно и то же старое
  значение, хотя устройство давно сменило статус.
- Считать, что `volatile` защищает от гонки между несколькими ядрами процессора → в
  многоядерном коде это не так, нужны барьеры памяти или атомики → гонка, не ловится
  однопоточным тестированием.

**Факты для карточек**
- base | Что делает `volatile` с точки зрения компилятора? — заставляет реально выполнять каждое обращение к памяти по адресу, не кэшируя значение в регистре и не убирая повторные чтения/записи
- core | Даёт ли `volatile` атомарность или барьер памяти между несколькими ядрами CPU? — нет, только запрещает компилятору кэшировать/убирать обращения к конкретной переменной
- core | Какая функция ядра отображает физический адрес MMIO-региона в виртуальный адрес для доступа как к указателю? — `ioremap()`
- deep | Зачем нужен `wmb()` между записью DMA-дескриптора и записью в регистр запуска устройства? — без барьера порядок этих двух записей, как его видит железо, не гарантирован, и устройство может прочитать старое содержимое дескриптора раньше, чем увидит новые данные

Ссылки на задачи этого набора: `tasks/07_epoll` — то, как ядро уведомляет процесс о готовых
событиях на файловых дескрипторах (тот же принцип «пользовательский процесс не опрашивает
железо/сеть напрямую, а получает уведомление от ядра», что и в syscall-границе раздела 1);
`tasks/03_ring` — кольцевой буфер head/tail, структурно совпадающий с DMA-кольцами в
драйверах (раздел 11).

<details>
<summary>Проверь себя</summary>

1. Почему нельзя просто разыменовать указатель, пришедший из пользовательской программы,
   прямо внутри `.read` драйвера?
   <details><summary>Ответ</summary>Это указатель в чужом (пользовательском) адресном
   пространстве: соответствующая страница памяти может быть не загружена или указатель
   вообще некорректен. Прямое разыменование либо роняет ядро (oops), либо блокируется
   аппаратно на CPU с SMAP/SMEP. Нужно использовать `copy_from_user`/`copy_to_user`, которые
   безопасно обрабатывают этот переход.</details>

2. На плате обновили дистрибутив ядра, но модуль устройства продолжает работать без
   пересборки под новую хардкод-конфигурацию регистров. За счёт какого механизма это
   возможно и что бы сломалось без него?
   <details><summary>Ответ</summary>Device tree: адреса регистров и конфигурация железа
   вынесены в `.dtb`, отдельный от кода ядра, и подгружаются загрузчиком при старте. Без
   device tree адреса были бы зашиты в код драйвера (board files), и под каждое изменение
   конфигурации платы пришлось бы переписывать и пересобирать сам код ядра.</details>

3. Драйвер читает статус-регистр устройства в цикле, ожидая, пока значение изменится, но
   переменная объявлена без `volatile` — цикл не завершается, хотя железо статус давно
   сменило. В чём причина и как это чинится?
   <details><summary>Ответ</summary>Компилятор решил, что раз в теле цикла переменная кодом
   программы не изменяется, можно прочитать её из памяти один раз и дальше сверяться с
   закэшированным в регистре значением — оптимизация, законная для обычной переменной, но
   ломающая логику для регистра, который меняет само железо. Нужно объявить указатель на
   регистр как `volatile`, чтобы компилятор перечитывал память при каждой
   итерации.</details>

4. Почему для системного вызова на x86-64 нужна специальная инструкция `syscall`, а не
   обычный вызов функции ядра через `call` по известному адресу?
   <details><summary>Ответ</summary>Обычный `call` не меняет уровень привилегий процессора —
   пользовательская программа в кольце 3 так и осталась бы в кольце 3, не получив доступа к
   привилегированным операциям ядра. `syscall` — специальная инструкция, которая одновременно
   переключает CPU в кольцо 0 и передаёт управление фиксированному обработчику ядра, что
   обычный переход по адресу сделать не может.</details>

</details>

## Материалы

- sysprog21.github.io, Linux Kernel Module Programming Guide (LKMPG) — https://sysprog21.github.io/lkmpg/
- docs.kernel.org, sysfs — https://docs.kernel.org/filesystems/sysfs.html
- docs.kernel.org, "volatile" Considered Harmful — https://docs.kernel.org/process/volatile-considered-harmful.html
- man7.org, `syscall(2)` — https://man7.org/linux/man-pages/man2/syscall.2.html
- man7.org, `ioctl(2)` — https://man7.org/linux/man-pages/man2/ioctl.2.html
- man7.org, `proc(5)` — https://man7.org/linux/man-pages/man5/proc.5.html