модули ядра (римэйк)

[Olej]

Подавляющее большинство модулей ядра, 100% собиравшиеся на уровне ядра 3.0, сейчас не собираются. Большая часть таких ошибок исправляется легко, это мелкие несоответствия. Но есть и радикально серьёзные изменения.

1). Это самая безобразная часть - что все предыдущие наработки перестают даже компилироваться при малых изменениях версий ядра

2). Но есть здесь и ещё сложность:
- а что делать со старыми версиями (кодами, примерами)?
- просто выбросить - проще всего, но в разных областях: встроенные, роутеры всякие, сетевое оборудование - до сегодня эффективно используются версии ядра 3.ХХ ... а 4.ХХ - так уже просто экзотика.
Обкладывать дефайнами куски кода (условной трансляцией) - не вариант: примеры просто нечитабельное + мне работы на порядок больше отслеживать версии...
Пока решение будет такое: примеры переделываю только под последние ядра 5.4-5.15, а в каждый каталог тематический включается каталог old_version, в котором подкаталоги: 2.6.38 ... 3.13 ... 4.11 ...

3). И сложности с отладкой: малейшая ошибка в переделке уже работающего - и O-ooops ... И перезагрузка. Это требует уйму времени.
Решение: отлаживать всё первоначально только в виртуальных машинах, потратить время на подготовку целой линейки таких машин ... И только на вылизывании чистовых деталей делать это на реальном железе.

[Olej]

3). И сложности с отладкой: малейшая ошибка в переделке уже работающего - и O-ooops ... И перезагрузка. Это требует уйму времени.
Решение: отлаживать всё первоначально только в виртуальных машинах, потратить время на подготовку целой линейки таких машин ... И только на вылизывании чистовых деталей делать это на реальном железе.

Что-то вот такое ... Только реально нужно не 3, а 4-5-6 разных дистрибутивов, разной разрядности - 32 и 64, и разной архитектуры: x86, ARM ... Всем, кто попытается успехов в разработке модулей ядра Linux, в написании драйверов - настоятельно советую: потратить изначально некоторое время, и создать такой вот примерно испытательный стенд. Тем самым вы, потратив вначале на это время, сэкономите в итоге уйму времени!

Код: Выделить всё

olej@lmde64:~$ inxi -Sxxx
System:
  Host: lmde64 Kernel: 5.10.0-15-amd64 x86_64 bits: 64 compiler: gcc 
  v: 10.2.1 Desktop: Cinnamon 5.2.7 tk: GTK 3.24.24 wm: muffin 5.2.1 
  dm: LightDM 1.26.0 Distro: LMDE 5 Elsie base: Debian 11.2 bullseye 

Код: Выделить всё

olej@lmde32:~$ inxi -Sxxx
System:
  Host: lmde32 Kernel: 5.10.0-15-686 i686 bits: 32 compiler: gcc v: 10.2.1 
  Desktop: Cinnamon 5.2.7 tk: GTK 3.24.24 wm: muffin 5.2.1 
  dm: LightDM 1.26.0 Distro: LMDE 5 Elsie base: Debian 11.2 bullseye 

... и т.д.
... и т.п.

[Olej]

Пока решение будет такое: примеры переделываю только под последние ядра 5.4-5.15, а в каждый каталог тематический включается каталог old_version, в котором подкаталоги: 2.6.38 ... 3.13 ... 4.11 ...

Вот как-то это будет иметь место так - в каждом целевом каталоге (network, procfs, sysfs, ...):

Код: Выделить всё

olej@R420:~/2022/own.BOOKs/BHV.kernel/ex_ready$ tree -L 2 network/
network/
├── Makefile
├── net
│   ├── devices.1.c
│   ├── devices.2.c
│   ├── devices.c
│   ├── Makefile
│   ├── mulnet.1.c
│   ├── mulnet.2.c
│   ├── mulnet.c
│   ├── net.1.hist
│   ├── net.2.hist
│   ├── net.3.hist
│   ├── net.4.hist
│   ├── net.5.hist
│   ├── net.6.ARM.hist
│   ├── net.6.Fedora.hist
│   ├── net.6.hist
│   ├── network.c
│   ├── receive.c
│   ├── transmit.c
│   ├── transmit_simple.1.c
│   └── transmit_simple.c
├── network.1.hist
├── network.2.hist
├── old_vers
│   ├── 3.14
│   ├── 3.17
│   └── Makefile
└── virt
    ├── Makefile
    ├── virt1.c
    ├── virt.1.hist
    ├── virt2.c
    ├── virt.2.hist
    └── virt.c

5 directories, 30 files

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

Код: Выделить всё

SUBDIRS=$(shell find . -maxdepth 1 -mindepth 1 -type d -printf "%f\n")
KARCH=kernel.modules.tgz

all clean disclean:
        @list='$(SUBDIRS)'; for subdir in $$list; do \
           echo "=============== making $@ in $$subdir ================="; \
           (cd $$subdir && make $@) \
        done
...

Исключение составляют каталоги old_vers во всех целевых каталогах - который только очищает, но не делает сборки :

Код: Выделить всё

SUBDIRS = $(shell find . -maxdepth 1 -mindepth 1 -type d -printf "%f\n")

all:
        @echo --- эти примеры требуют индивидуальной сборки

clean disclean:
        @list='$(SUBDIRS)'; for subdir in $$list; do \
           echo "=============== making $@ in $$subdir ================="; \
           (cd $$subdir && make $@) \
        done

[Olej]

Вот как-то это будет иметь место так - в каждом целевом каталоге (network, procfs, sysfs, ...):

Возможно ( ) ... и назрела необходимость 1). оформить опыты с модулями ядра в виде GIT-репозитория и 2). разместить это на одном из сетевых репозиториев (GitLab, GitHub, Bitbucket ...).

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

Но ... сказано - сделано.
Откладываю ревизию кодов к книге + отвлекаюсь на некоторое время на создание локального репозитория GIT + на размножение его через каките-то публичные облачные ресурсы...

[Olej]

А вот и 2-я: драйвера сетевых устройств.

Вот 3-я часть: трюки в модулях ядра.
Здесь всякая экзотика...
Без особых комментариев - пока это римейк того, что было в книге 2015 года - все объяснения можно найти там.
А вот детали команд, как это всё запускалось ... протоколы - это во вложенных файлах *.hist

[Olej]

Откладываю ревизию кодов к книге + отвлекаюсь на некоторое время на создание локального репозитория GIT + на размножение его через каките-то публичные облачные ресурсы...

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

[Olej]

1). Это самая безобразная часть - что все предыдущие наработки перестают даже компилироваться при малых изменениях версий ядра

Интересно то, что "линия совместимости" по самым разным образцам-примерам ломается чаще всего на определённых, одних и тех же версиях ядра. Наверное, именно в этих точках накапливаются радикальные изменения (часто связанных с переносом прототипов kernel API даже в другие файлы определений *.h).
Последними такими "точками перелома" являлись, почему-то, версии ядра 4.19 и далее 5.10 ...

[Olej]

Ещё одна "фишка" из области модулей ядра - DKMS (Dynamic Kernel Module Support), динамическое обновление модулей при обновлениях ядра из менеджера пакетной системы. При обновлениях (apt или dnf) из пакетной системы, когда обновляется подверсия ядра, модули из дерева исходных кодов ядра будут обновляться автоматически, одновременно с обновлением ядра, потому что эти модули компилированы под это именно ядро.

Но вот все модули, установленные вручную (со стороны), станут недействительными, и их нужно собирать и инсталлировать вручную. Для тех (массово) пользователей, кто не "на ты" с программированием и системой - это совсем не лёгкое испытание. И вот для этого и придумана позже подсистема DKMS - модули поставленные под её контроль, собираются автоматически при обновлениях ядра.

Про то как это делается есть уже отдельная тема: автоматическая сборка модулей ядра (DKMS) - только её пришлось обновить...

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

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

[Olej]

Пересматриваю тексты, а, самое главное, коды примеров к текстам - Драйверы и модули ядра Linux:

Если кого это (драйвер/модули ядра Linux) заинтересует, то вот промежуточная версия на сегодня (но то что находится в работе).
Kernel.7270.odt - текст:

Linux: драйверы и модули ядра
Проект книги
Редакция 7.270
стр. 451

редакция 270 (7 - это групповой номер, не важно) означает, что я над этим текстом с примерами работал 270 более-менее полных рабочих дней.

[Olej]

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

Вопрос решился ...
Компьютерное издательство BHV будет издавать огромную книгу с рабочим названием "Расширения ядра Linux: драйверы и модули" и будет это делать скоро, возможно даже до Нового Года.
На сегодня (работа продолжается ) в рукописи 474 страницы A4 LibreOffice ... книжного формата это будет много больше, не знаю, не могу сказать точно (это издатели умеют считать хорошо ), страниц под 700 наверное.

Вопрос был даже не столько в желаниях издательства BHV сколько в том, что я, начав ревизию уже имеющегося текста в мае-июне - уже собирался отказаться ... потому что это неподъёмная работа: ревизировать всё это под свежие ядра Linux. Первоначальный текст (но самое главное - работающие примеры к тексту) начал складываться в 2011 году, как заказной тренинговый (учебный) курс для программистов-разработчиков междунаолдной софтверной компании GlobalLogic. Это время ядра порядка 2.6.32-2.6.38.
Да ещё мои наброски кодов за предыдущие 5 лет непрерывной (в штате) работы в крупнейшем разработческом проекте в этой области под CentOS 5.2 - а это ядро примерно 2.6.18.
Следующие радикальные ревизии относились к годам, периодам, 2014-2016, и всё было подогнано до версий 3.18.-3.19.
Так вот сейчас это предстояло ревизировать коды а соответствие ядрам 4.19 и 5.10 (это почему то оказались "переломные точки" в совместимости API ядра). А компилировалось только около 40% общего объема примеров. А общий объём там (на сейчас уже) текстовых файлов :

Код: Выделить всё

olej@R420:~/2022/own.BOOKs/BHV.kernel$ du -hs examples 
8,3M	examples

И число файлов которые нужно компилировать, выверить выполнением и переделать:

Код: Выделить всё

olej@R420:~/2022/own.BOOKs/BHV.kernel$ tree examples | grep '\.h' | wc -l
245

Код: Выделить всё

olej@R420:~/2022/own.BOOKs/BHV.kernel$ tree examples | grep '\.c' | wc -l
361