Збірка модулів ядра

Модулі ядра [ред]

Ядро Linux містить в собі безліч коду, що підтримує ту чи іншу можливість або обладнання. Основна частина цього коду (зазвичай це код підтримки процесорів, пам'яті та інших базових речей) вкомпільовані в ядро і завантажується з ним, а частини коду, необхідні тільки частини користувачів - драйвери пристроїв, підтримка файлових систем, і т.д. - зібрані у вигляді модулів.

Модулі можуть підключатися до ядра по команді користувача (modprobe. Insmod) або автоматично за допомогою udev, і бути вивантажені або самим ядром, або командою rmmod.

Більшість модулів знаходиться в пакеті ядра, однак іноді з технічних, адміністративних або юридичних причин деякі модулі збираються окремо.

Про модулях і назвах [ред]

Оскільки в репозиторії може бути безліч ядер, модулі збираються особливим способом: є пакет з вихідними кодами модуля, і пакети з модулями, зібраними для конкретного ядра. При цьому SRPM останніх містить тільки .spec і патчі, а вихідні коди отримує по складальним залежностям. Таким чином, для модуля module і варіанти ядра flavour у нас є пакети з іменами

kernel-source-module - містить тільки вихідні
kernel-modules-module -flavour - модуль module. зібраний для ядра flavour (наприклад, kernel-modules-nvidia-std-def)

Поле release пакетів з модулями заповнюється так: alt... де

- реліз власне модуля, тобто, якщо ми оновили саме модуль, то це поле змінюється;
- версія ядра в форматі (2 ^ 16) * major + (2 ^ 8) * mid + minor. тобто 2.6.25 = 132633. Не лякайтеся, це число розраховує скрипт, описаний пізніше;
- реліз пакету з ядром.

Наприклад, модуль з nvidia для ядра kernel-image-std-def-2.6.25-alt8 буде називатися kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8.

Як зібрати модуль локально [ред]

Дана фаза потрібна в першу чергу для тестування модуля, і, в общем-то, не обов'язкова, але корисна для розуміння процесу.

Що нам потрібно [ред]

Крім gcc, make і інших стандартних складальних речей нам потрібно kernel-headers-modules- (І все що від нього залежить). Цей пакет містить ту частину вихідних кодів, заголовків файлів, make-файлів і скриптів, які необхідні для складання модулів для даного ядра.

Збірка [ред]

Завантаживши і розпакувати вихідні модуля, ми виявимо що просто make зазвичай не працює. Ця проблема стосується виключно Sisyphus / ALT Linux і полягає в тому, що для складання модуля необхідні заголовки ядра, які шукаються в каталозі / lib / modules // Build. але не можуть бути знайдені там, тому що в ALT Linux і Sisyphus доступ користувачам в / lib / modules / заборонений.

Для того, щоб обійти цю проблему, потрібно перевизначити змінну (зазвичай KERNELSOURCE або KSRC) в Makefile. Далі запускаємо збірку, наприклад make KSRC = / usr / src / linux-2.6.25-std-def. Зазвичай модуль після цього збирається.

Зібраний модуль можна спробувати завантажити за допомогою insmod. або покласти його до інших модулів ядра в / lib / modules / і завантажити modprobe. Якщо модуль завантажився і працює, то можна переходити до наступної частини.

Як зібрати модуль правильно [ред]

Чому попередній спосіб не є правильним? Тому що він недістрібутівен. Для нормальної зборки нам потрібні:

Шаблони [ред]

Оскільки правити спеки кожного пакета з модулями для кожної версії ядра дещо безглуздо, була розроблена схема, при якій для кожного модуля створюється шаблон, а gear (за допомогою директиви specsubst. В якій вказується flavour ядра) підганяє цей шаблон до конкретного ядра (в тому числі обчислює реліз модуля). Решта роботи лягає на макрос% setup_kernel_module. який обчислює всі інші параметри, потрібні для збірки модуля: версію ядра, реліз ядра і реліз модуля. Самі шаблони зберігаються в git-репозиторії, в якому є безліч гілок, гілки з шаблонами називаються template / module / distro. де module - це власне назва модуля (наприклад, nvidia) а distro - це те, під що ми збираємо. Зазвичай це sisyphus. але, оскільки для різних бранчів шаблони доводиться міняти, можна встановити поле distro в відповідне значення. Зазвичай distro зараз збігається з ім'ям бранча.

Підготовка робочої директорії [ред]

Нам будуть потрібні утиліта km-create-tag для збірки модулів з пакету kernel-build-tools.

Для використання бранчів з шаблонами доведеться їх завести локально, наприклад:

Збірка модуля з шаблону (за допомогою gear-specsubst) [ред]

Коли ви збираєте локально в тестових цілях, зручно встановити параметр gear.specsubst.kflavour з вашим ядром:

Після цього модуль можна зібрати за допомогою команди:

Створення тегів для збірки на git.alt (схема з gear-specsubst) [ред]

Наприклад, для створення тега для модуля nvidia, що збирається для ядра std-def:

Або, для створення тегів для всіх модулів, можна зробити:

Збірка модулів на git.alt [ред]

Після цього можна запущено отримані бранчі і теги на git.alt.

і додати список модулів до останнього task'у (де імовірно вже доданий на збірку відповідний kernel-image):

Слід, однак, враховувати, що updatemodules і km-create-tag не затертого файл out / taglist і вам потрібно робити це вручну.

Якщо ж ви оновлюєте ядро, але не збираєтеся оновлювати шаблони модулів, можна зробити:

$ Ssh git.alt task add [номер завдання] kmodules std-def

це додасть в завдання (де імовірно вже доданий на збірку відповідний kernel-image) всі модулі, зібрані для ядра std-def.

Деякі моменти [ред]

Якщо в репозиторії: kernel-image-std-def-3.0.4-alt0.M60P.1.i586.rpm
Тоді в імені пакету: kernel-modules-emlog-std-def-0.51-alt2.196612.0.M60P.1.i586.rpm

У реліз модуля запаковується версія + реліз ядра. СТРАШНО?

Пересобрать окремо один модуль [ред]

Припустимо потрібно пересобрать в репозитарій якийсь модуль без пересборки ядра і всіх модулів.

Змінюємо гілку template / rt3070 / sisyphus, коммітов наші зміни
km-create-tag -k std-def rt3070
перевіряємо збірку чимось на кшталт: gear -t $ (git describe) --hasher - hsh $ TMP /

Збірка нового модуля [ред]

Збірка kernel-source-module [ред]

Для початку нам варто зібрати пакет з кодами модуля. Цей пакет простий, і фактично містить в собі тільки упаковані вихідні, а його збірка складається тільки в запаковування. Для прикладу краще взяти що небудь нескладне і готове, наприклад, зробити так:

Редагуємо за образом і подобою kernel-source-module .spec - зазвичай там треба замінити ім'я модуля, версію, опис та changelog, а сам процес складання зазвичай можна не чіпати.

Далі збираємо пакет за допомогою gear. В результаті в пакеті повинен виявитися всього один файл, а саме / usr / src / kernel / sources / kernel-source-module .tar.bz2

Зверніть увагу на те, що деякі пакети з вихідними кодами в своєму імені містять версію. наприклад, kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1. Це зроблено для того, щоб можна було мати можливість збирати різні версії ядер з різними версіями модулів (наприклад, нові модулі не збираються з 2.6.18).

Створення нового шаблону [ред]

Після складання пакета з вихідними кодами модуля, нам потрібно створити нову гілку в репозиторії з модулями:

де module - назва вашого модуля.

Тепер редагуємо спік, міняємо: ім'я, версію, опису, чейнджлог, можливо треба буде поправити опції для збірки. І коммітов:

Увага, верхня запис changelog повинна залишатися незмінною і складатися з тих страшних макросів, з яких вона складається в будь-якому модулі ядра в будь-якому актуальному репозиторії ALT

Як викласти свій модуль в репозиторій [ред]

Викладання модулів нічим не відрізняється від викладання звичайних пакетів.

Викладаємо власне модуль:

Залишилося зібрати пакети через git.alt.

Важливе зауваження: для того щоб збірка пройшла правильно, kernel-source-module повинен бути зібраний до збірки kernel-modules-module.

Про symvers і модулі залежать від інших модулів [ред]

Іноді буває, що пакет з модулями, повинен збиратися під інший пакет з модулями. Так наприклад просіходіт з gspca і v4l. Для нормальної зборки нам потрібно 2 речі: по-перше, проставити правильно залежності на headers (у v4l є свої хедери), по-друге, потрібно імпортувати файл з symvers. У gscpca проблема вирішилася додаванням наступного рядка в% prep фазу пакета з модулем gspca:

Схожі статті

Попередня ◈ Наступна