Alt linux kernel header

Сборка модулей ядра

Содержание

Модули ядра [ править ]

Ядро 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 . Если модуль загрузился и работает, то можно переходить к следующей части.

Как собрать модуль правильно [ править ]

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

• знание git (крайне желательно хотя бы начальное знание!)
• умение пользоваться gear и hasher
• настроенный hasher
• доступ на git.alt (для публикации результатов)
• достаточно терпения

Шаблоны [ править ]

Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, была разработана схема, при которой для каждого модуля создается шаблон, а 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 с вашим ядром:

После этого модуль можно собрать с помощью команды:

Управление архитектурами, для которых собираются модули [ править ]

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

Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность:

В файле .gear/km-karch может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox:

Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64

Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян).

Для того, чтоб это работало, в спек файле должны быть строки:

А в .gear/rules файле строка:

Создание тегов для сборки на 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

В релиз модуля запаковывается версия + релиз ядра. СТРАШНО?

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

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

Ветка kernel-modules-rt3070-std-def/sisyphus — должна быть вытянута последняя из http://git.altlinux.org/gears/

1. Изменяем ветку template/rt3070/sisyphus, коммитим наши изменения
2. km-create-tag -k std-def rt3070
3. проверяем сборку чем-нибудь вроде: 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.

Рекомендации по взаимодействию с мейнтейнерами ядер [ править ]

Для нормальной совместной работы рекомендуется:

• При обновлении модуля обновлять сборки под максимальное количество ядер
• Своевременно обновлять шаблоны в репозитории на git.alt
• Оповестить мейнтейнеров ядер (в списке рассылки devel-kernel), о том что есть ваш модуль,
• Настроить git remote на kernel-modules других мейнтейнеров,
• В спеках kernel-modules- поле Packager установить в Kernel Maintainers team.

Про symvers и модули зависящие от других модулей [ править ]

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

Источник

Alt linux kernel header

Поиск

Поддержка

Погода

Статистика

Рейтинг

CIFS@Etersoft (etercifs) — это заплатка/надстройка для cifs-протокола для запуска сетевых windows-приложений.

Чтобы она корректно собиралась и запускалась в ALT Linux необходимо:

Установить пакеты:
kernel-headers-modules-std-smp и kernel-source под используемую версию ядра Linux в системе.
Выглядеть это может примерно следующим образом: где std-smp — тип используемого ядра Linux,
2.6.30 — версия используемого ядра Linux.
Узнать тип и версию используемого в системе ядра Linux можно по выводу команды:
следует отметить, что если используется репозитарий из интернета, от по команде:

может скачаться и установиться пакет НЕ под версию 2.6.30 (как в нашем примере), а более свежая версия пакета kernel-headers-modules-std-smp — 2.6.32. Из-за этого пакет etercifs не будет собираться на последнем 4-ом шаге.

Если такое произошло, то необходимо самим разыскать пакет kernel-headers-modules под ваш тип и версию ядра, например: kernel-headers-modules-std-smp-2.6.30-alt14.i586.rpm, и установить вручную, например командой:

Скорректировать в файле /root/.bash_profile строку с системной переменной PATH:

Стандартная строка в файле (не полная, к сожалению): Правильная строка, которая и должна быть по умолчанию: Ключевую роль играют вот эти 4 каталога: После внесёных изменений в файл /root/.bash_profile проинициализируем переменные из него командой:
(в начале строки точка)

Прописывание бинарных каталогов в переменную обзора PATH и его инициализация необходимы для скрипта сборки etercifs, в частности для используемой в скрипте команды lsmod.

Теперь можно установить etercifs:

но лучше взять последнюю версию etercifs под свой дистрибутив у разработчика по ссылке: CIFS@Etersoft

Источник

Alt linux kernel header

ALT LINUX KERNEL 2.6 HOWTO

Дата последнего изменения: Чтв Фев 26 10:37:11 EET 2004

Этот документ предназначен для пользователей ALT Linux, желающих
насладиться преимуществами использования ядра Linux версии 2.6.X

1. Установка готового ядра
—————————
Все нижеперечисленное относится к установке на
Sisyphus, Compact, ALT Linux Master 2.2.
Версии пакетов для ALM 2.2 нужно искать в подкаталогах с именем ALM2.2
Версии пакетов для Compact — в подкаталогах с именем Compact

1.1 Устанавливаем следующие пакеты:
mkinitrd
modutils (можно взять из Сизифа)
bootloader-utils
initscripts (только на ALM 2.2)

Для Compact:
Все, у кого установлен startup-0.7-alt1, могут безболезненно обновить
этот пакет до 0.8-alt1 либо 0.8.1-alt1 из Sisyphus.
Тем, у кого startup = 0.7-alt1 лучше
всего делать dist-upgrade’ом.

1.2 Можно установить еще и это (необязательно):
libsysfs
sysfsutils

1.3 Правим конфигурационные файлы:

Для поддержки sysfs добавляем следующую строку в /etc/fstab:
none /sys sysfs defaults 0 0

Для загрузки драйвера PS/2 мыши добавляем это в /etc/modules:
psmouse

Для работы звука добавляем драйвер звуковой карты:
alias snd-card-0 snd-cmipci
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
В примере используется драйвер snd-cmipci, драйвер своей звуковой
карты можно попытаться найти ниже /lib/modules/2.6.1-std26-up-altX/kernel/sound/)

Для загрузки драйвера COM-порта добавляем его алиас :
# RS232
alias char-major-4 8250

Изменилось название модулей USB с ehci-hcd usb-ohci usb-uhci на
ehci-hcd ohci-hcd uhci-hcd соответственно.
Вот пример для uhci:
#alias usb-interface usb-uhci
alias usb-interface uhci-hcd

Добавляем алиасы для модуля поддержки пакетной записи
# Packet CD writing
alias block-major-97 pktcdvd
alias /dev/pktcdvd1* pktcdvd

1.3 Cтавим собственно ядро:
kernel-image-std26-up

1.4 Ставим нужные модули:
для Sisyphus и Compact:
kernel-modules-nvidia-std26-up-5328

для ALM2.2:
Ставим модули kernel-modules-nvidia-std26-up-4191

1.5 Проверяем наличие нужной секции в lilo.conf,
или в конфиге grub-а, запускаем lilo для вступления изменений в силу.
Перезапускаем систему.
Все должно загрузиться и работать.

1.6 Если что-то не работает, то пишем в devel-kernel@ или еще куда-нибудь.

2.2 Ставим kernel-build-tools
Читаем /usr/share/doc/kernel-build-tools-0.6/kernel-policy.txt опять
очень вдумчиво. Проникаемся.

2.3 Ставим kernel-image-std26-up-2.6.1-altX.src.rpm,
смотрим в его спек, находим там все, что нужно ему для сборки:
kernel-source-2.6.X
kernele-build-tools версии >= 0.6-alt3
coreutils dev86 bzip2 make tar flex
rpm >= 4.0.2-75 libdb4.0-devel
gcc-3.3
Несколько kernel-fix-* и kernel-feat-*
и ставим это.

Путь для занятых — пропускаем пункты 2.1 и 2.2, ставим kernel-image-std26-up-2.6.1-altX.src.rpm,
делаем rpm -bp kernel-image-std26-up.spec и смотрим что ему нужно по
многочисленным сообщениям rpm. Ставим это.

2.4 Делаем rpm -bp kernel-image-std26-up.spec и после завершения идем в `rpm —eval %_builddir`
идем в kernel-image-std26-up-2.6.1-altX/kernel-source-2.6.1/ и находим
там распакованые и пропатченые сорцы, готовые к сборке.

2.5 Накладываем свои патчи (необязательно)
Опакечиваем свои патчи согласно kernel-policy и прописываем их в спек kernel-image-std26-up

2.6 Берем конфиг в `rpm —eval %_sourcedir` для kernel-image-std26-up
копируем его (config-2.6.1-std26-up) в ./.config
Делаем make menuconfig и конфигуряем ядро на свой страх и риск.
Копируем получившийся ./config обратно в %sourcedir

2.7 Делаем rpm -ba kernel-image-std26-up.spec и долго ждем.
Если мы все сделали правильно, то получаем в результате что-нибудь
типа этого:
Wrote: /sandman/SRPMS/kernel-image-std26-up-2.6.1-alt5.src.rpm
Wrote: /sandman/RPMS/i586/kernel-image-std26-up-2.6.1-alt5.i586.rpm
Wrote: /sandman/RPMS/i586/kernel-headers-std26-up-2.6.1-alt5.i586.rpm
Wrote: /sandman/RPMS/i586/kernel-headers-modules-std26-up-2.6.1-alt5.i586.rpm

2.8 Собираем нужные модули для нашего нового ядра:
Процесс описан для модуля nvidia:
Ставим kernel-source-nvidia-4496-1.0.4496-alt4.noarch.rpm
Ставим kernel-headers-std26-up и kernel-headers-modules-std26-up
для нашего(. ) ядра (см. п. 2.7)
Делаем rpm —rebuild kernel-modules-nvidia-std26-up-1.0.4496-alt9.src.rpm

2.9 Плавно переходим в начало данного текста и читаем как это ставить.

4. Disclaimer: Все вышесказанное ни на что не претендует и автор ни за
что не несет ответственности.

Источник