Alt linux kernel headers

3 ДЕЛБВТС 2018 Gleb F-Malinovskiy 1.2.7-alt1

Added support of mips*, s390x, riscv64, and power* architectures.

16 СОЧБТС 2016 Michael Shigorin 1.2.6-alt1

Added e2k architecture support.

28 УЕОФСВТС 2015 Gleb F-Malinovskiy 1.2.5-alt1

Added aarch64 architecture support.

20 ЙАОС 2013 Gleb F-Malinovskiy 1.2.4-alt1

Added kheaders.filetrigger for kernel headers adjustment.

14 ЖЕЧТБМС 2013 Gleb F-Malinovskiy 1.2.3-alt1.1

Rebuilt for newer %arm macro.

12 НБС 2012 Dmitry V. Levin 1.2.3-alt1

Added kheaders.service.

12 НБС 2012 Dmitry V. Levin 1.2.2-alt1

Added a workaround for update problems (closes: #27320).

11 НБС 2012 Dmitry V. Levin 1.2.1-alt1

Packaged /usr/include/asm-%_target_cpu symlink to make packages
always different on different architectures.

4 БРТЕМС 2012 Dmitry V. Levin 1.2.0-alt1

Added /usr/include/ symlinks.
On %ix86 and x86_64, replaced obsolete /usr/include/asm-
symlinks with /usr/include/asm-x86.

17 БРТЕМС 2009 Dmitry V. Levin 1.1.11-alt1

adjust_kernel_headers: Added branch kernels support (closes: #19641).

9 НБТФБ 2009 Dmitry V. Levin 1.1.10-alt1

Added ARM support (Kirill A. Shutemov).
Suppressed dependencies autogenerated for dangling
/usr/include/asm-* symlinks (closes: #18592).

26 ОПСВТС 2006 Sergey Vlasov 1.1.9-alt1

Added /usr/include/asm-$ARCH symlinks (required for Linux 2.6.18 headers on
x86_64, and sometimes used even in older versions).
Package is no longer noarch (the set of asm-$ARCH symlinks is arch-specific:
asm-i386 on 32-bit x86, both asm-x86_64 and asm-i386 on x86_64).
Used explicit list instead of %_includedir/* in %files (otherwise rpmbuild
does not put files which happen to be dangling symlinks into the package).
Terminate build if unpackaged files were found.

25 ОПСВТС 2006 Sergey Vlasov 1.1.8-alt1

adjust_kernel_headers: Decrease linux/version.h size threshold to 90 bytes
(fixes problems with Linux 2.6.18 headers, where linux/version.h became
smaller due to UTS_RELEASE removal).
Removed all %__* macro abuse from spec.

30 СОЧБТС 2006 Sergey Vlasov 1.1.7-alt1

adjust_kernel_headers:
+ always give «default» headers (glibc-kernheaders) lowest priority when
using —first to enable use of linux-libc-headers with hasher (#8918);
+ fix bashism noted in comment to #8422.

2 ДЕЛБВТС 2005 Sergey Vlasov 1.1.6-alt1

adjust_kernel_headers:
+ applied linux-libc-headers support patch from Konstantin A Lepikhov
(#8422).

25 НБС 2005 Sergey Vlasov 1.1.5-alt2

Spec fixes for x86_64 compatibility from mouse@ (#6538).

8 НБТФБ 2004 Sergey Vlasov 1.1.5-alt1

adjust_kernel_headers:
+ added auto and manual modes;
+ added proper «—help» text;
+ added «—version» option;
+ fixed old-style headers handling (even if usable version.h exists in
/usr/lib/kernel/$VERSION, do not consider the headers available unless
something reasonable exists in /usr/lib/kernel/include);
+ cleanup suggested by Dmitry V. Levin .
Added man page for adjust_kernel_headers.
Added triggers for glibc-kernheaders, kernel-headers-std-,
kernel22-headers, kernel24-headers and also %triggerpostun for old kernel
packages (which contained part of the kernel headers) to fix headers on
install/uninstall.
Added /usr/include/asm-generic symlink (needed by 2.6.x kernel headers).

30 ЙАМС 2003 Dmitry V. Levin 1.1.4-alt1

adjust_kernel_headers:
+ added «—list» option;
+ added «—first» option.

3 ЙАОС 2003 Dmitry V. Levin 1.1.3-alt1

init.d/kheaders: fixed $LOCKFILE handling.

2 ЙАОС 2003 Dmitry V. Levin 1.1.2-alt1

adjust_kernel_headers:
+ fixed KERNEL_VERSION definition;
+ better kernel autodetection.

22 НБС 2003 Dmitry V. Levin 1.1.1-alt1

adjust_kernel_headers: better —help support.

20 НБС 2003 Dmitry V. Levin 1.1-alt1

Updated to support new kernel headers scheme.

18 ОПСВТС 2002 Stanislav Ievlev 1.0-alt2

rebuild

15 БЧЗХУФБ 2001 Dmitry V. Levin 1.0-alt1

Initial revision.

Источник

Linux-ru

Форум по операционной системе GNU/Linux и свободному программному обеспечению

Непрочитанные сообщения
Темы без ответов
Активные темы
Поиск
Пользователи
Наша команда

ALT Linux

Непрочитанное сообщение Olej » 09 июн 2015, 14:43

Altlinux

Непрочитанное сообщение Olej » 24 июн 2016, 19:17

Это даже странно как-то обнаружилось, что в форуме нет даже темы про Altlinux.
Тем не менее, это старейший дистрибутив отечественной сборки (я помню, что Altlinux стоял у меня ещё на каком-то 386-м процессоре . и это, наверное, был оди из первых Altlinux).

И восполняя. заведём тему, как раз по случаю выхода свежего релиза: Выпущена Восьмая платформа BaseALT (p8)

Фирма «Базальт СПО» (BaseALT) сообщает о выходе Восьмой платформы BaseALT (p8), новой стабильной инфраструктуры репозиториев пакетов свободных программ, предназначенной для разработки, тестирования, распространения, обновления и поддержки комплексных решений, созданной и развиваемой в рамках проекта Sisyphus командой ALT Linux Team.

Особое внимание разработчики уделили свободным решениям уровня предприятия, позволяющим корпоративным пользователям осуществить миграцию с проприетарной инфраструктуры и широко использовать современные системы управления виртуализацией. Для быстрого начала работы с Восьмой платформой, BaseALT предлагает пользователям, предпочитающим самостоятельно определять состав и оформление системы, загрузочные образы комплектов входа (starter kits) для архитектур i586 и x86_64 в 13 вариантах окружений рабочего стола и 9 вариантах для серверов, облачных решений и задач администрирования системы.

Новые стабильные решения на основе Восьмой платформы для различных категорий пользователей будут выпущены в июне-августе 2016 года. Репозиторий для архитектуры AArch64 (64-битный ARM) будет выпущен в июле 2016, до конца осени планируется выпуск репозитория для отечественной аппаратной платформ «Эльбрус».

Источник

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

Содержание

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

Ядро 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/

Изменяем ветку 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:

Источник

Читайте также: Скайп линукс по русски

Alt linux kernel headers