[d-kernel] [RFC] kernel-policy 1.2

[d-kernel] [RFC] kernel-policy 1.2

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 874 bytes --]

Hello!

На обсуждение выносится исправленная и дополненная редакция
kernel-policy.  Изменений достаточно много:

- Добавлено описание средств для условного применения патчей (часть
  этих возможностей уже была в kernel-build-tools, но без
  документации; часть была добавлена в процессе работы над ядрами
  2.6.x).

- Добавлено описание макросов для пакетов с патчами (%source и
  %install_patches).

- Добавлены требования к зависимостям пакетов.  Возможно, часть
  зависимостей для совместимости в действительности лишняя (у меня
  есть сомнения по поводу Obsoletes: kernel-modules-i2c-%flavour -
  подозреваю, что при этом происходит не то, что имели в виду).

Пример spec-файла ядра пока удалён - он устарел, а текущие
spec-файлы перед включением в policy в качестве примера нуждаются в
чистке. :)

Прошу заинтересованных высказаться по этому поводу.

-- 
Sergey Vlasov

[-- Attachment #1.2: kernel-policy.txt --]
[-- Type: text/plain, Size: 16323 bytes --]

Kernel Policy for Sisyphus.
===========================

Version: 1.2


0. Документ и его обновление.
-----------------------------

kernel policy обновляется участниками kernel maintainer committee.
Состав kernel committee:
- Ed V. Bartosh
- Dmitry V. Levin
- Peter A. Novodvorsky
- Sergey Vlasov


1. Именование
-------------

1.1 Патчи.
----------

Есть два вида патчей:

kernel-feat-%{upstream_name}
kernel-fix-%{upstream_name}

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

В пакетах feat содержатся патчи, добавляющие ядру Linux новые
возможности. Это могут быть и драйверы устройств (рекомендуется
называть такие kernel-feat-drivers-<имя_устройства>), и файловых
систем (желательно называть kernel-feat-fs-<имя_файловой
системы>), добавление новых возможностей к сетевой подсистеме
(желательно называть kernel-feat-net-<сокращённое название
улучшения>), а также добавление новых возможностей к корневой части
(kernel/*, mm/*, arch/*) ядра, (желательно называть
kernel-feat-core-<название улучшения>). При именовании патчей
рекомендуется следовать иерархии каталогов в исходных текстах ядра.

Все пакеты fix поддерживаются kernel maintainer commitee. Именуются по
именам подсистем ядра, а также существует отдельный пакет для security
патчей и build патчей:
kernel-fix-{net,drivers,fs,vm,core,security,build}.

Глубина иерархии в названии пакета может варьироваться, некоторые
уровни - пропускаться, чтобы сделать название короче, например,
kernel-net-netfilter вместо kernel-net-ipv4-netfilter и
kernel-net-ipv6-netfilter.
 
1.2 Внешние модули.
-------------------

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

Пакеты с такими собранными модулями должны называться
kernel-modules-<сокращённое название набора модулей>-<flavour ядра с
которым собраны модули>.

Пакеты с заголовочными файлами этих модулей должны называться
kernel-headers-<сокращённое название набора модулей>-<flavour ядра с
которым собраны модули>.  Такие пакеты могут и не существовать, они
требуются лишь в том случае, когда эти заголовочные файлы требуются
для утилит или других модулей.

1.3 Пакеты с исходными текстами модулей.
----------------------------------------

Такие пакеты должны называться: kernel-source-<имя проекта>, либо
kernel-source-<имя проекта>-<версия модулей>, если требуется
одновременная установка нескольких версий такого пакета.

1.4 Пакеты с исходными текстами ядра.
-------------------------------------

Такие пакеты должны называться: kernel-source-<версия ядра без
суффикса (rc*|pre*)>. Версия такого пакета формируется по следующему
правилу: 
# 0.0.X -- preX
# 0.X.0 -- rcX
# 1.0.0 -- release

1.5 Пакеты с ядром.
------------------

Такие пакеты должен называться kernel-image-<flavour ядра>.

Пакеты с заголовочными файлами ядра должны называться
kernel-headers-<flavour ядра>.

Пакеты с внутренними заголовочными файлами ядра, которые необходимы
только для сборки модулей для этого ядра (например, внутренние
заголовки подсистемы SCSI), должны называться
kernel-headers-modules-<flavour ядра>.

1.6 Пакет kernel-build-tools
----------------------------
В этом пакете содержатся rpm определения, макросы, скрипты и другие
вспомогательные средства, которые рекомендуется использовать в spec
файлах kernel- пакетов и в apply скриптах. В том числе в файле
/etc/rpm/macros.d/kernel содержится макрос, который используется при
прикладывании патчей, если отсутствует приложенный apply скрипт.


2. Versioning пакетов.
----------------------

Пакетам с feat патчами желательно присваивать версии, полученные из
upstream. Если upstream не делает versioning, допустимо называть их по
дате последнего изменения upstream в формате yyyy.mm.dd.

Пакетам с fix патчами обязательно присваивать версии по дате
запаковывания в формате yyyy.mm.dd.

Пакетам с внешними модулями и ядром, а также с исходными текстами
модулей, желательно присваивать версии, полученные из upstream. Если
upstream не делает versioning, допустимо называть их по дате
последнего изменения upstream в формате yyyy.mm.dd.

Пакетам с исходными текстами ядра присваиваются версии по следующей
схеме: 
  - если это версия preX, то версия пакета будет 0.0.X.
  - если это версия rcX, то версия пакета будет 0.X.0.
  - если это релиз, то версия пакета будет 1.0.0.


3. Содержимое пакетов.
----------------------

3.1 Патчи.
----------

/usr/src/kernel/patches/<имя_пакета>/*            патчи
optional:
         kernel/patches/apply/<имя_пакета>        программа, которая
						  прикладывает патчи

Пакеты с патчами могут быть двух типов:

  1) Содержащие только патчи в формате unified diff (или context diff)
     для применения с помощью patch -p1, и не содержащие своей
     программы для приложения патчей.  В этом случае для применения
     патчей используется встроенный алгоритм из kernel-build-tools
     (см. раздел 5).

  2) Содержащие собственную программу (apply-скрипт) для приложения
     патчей.  В этом случае формат файлов, помещаемых в каталог
     /usr/src/kernel/patches/<имя_пакета>/, может быть любым.

3.1.1 Патчи без собственной программы для приложения
----------------------------------------------------

В простейшем случае пакет патчей может состоять из набора patch-файлов
в каталоге /usr/src/kernel/patches/<имя_пакета>.  Файлы с патчами
рекомендуется называть по шаблону "NN_name.patch", где NN -- номер
патча, определяющий порядок его приложения.

Если часть патчей в пакете нужно прикладывать не всегда, можно
использовать следующие средства:

  - Чтобы патч NN_name.patch не прикладывался к версии ядра X.Y.ZZ,
    нужно создать в том же каталоге пустой файл с именем
    dont_apply_to_X.Y.ZZ_NN_name.patch.

  - Для применения группы патчей только к определённой версии ядра
    (X.Y.ZZ) эти патчи следует поместить в подкаталог
    NN_apply_to_X.Y.ZZ.

  - Для применения группы патчей только к определённой ветке ядер
    (X.Y) эти патчи следует поместить в подкаталог NN_X.Y.

  - Если группу патчей необходимо прикладывать только в том случае,
    если ранее был применён другой пакет патчей (kernel-AAA-BBB), эти
    патчи следует поместить в подкаталог NN_kernel-AAA-BBB.  Если при
    обработке такого подкаталога обнаруживается, что указанный пакет
    патчей входит в список патчей для собираемого ядра, но ещё не был
    приложен, он прикладывается перед обработкой патчей из
    подкаталога.

  - Если группу патчей необходимо прикладывать только в том случае,
    если другой пакет патчей (kernel-AAA-BBB) не прикладывается к
    собираемому ядру, эти патчи следует поместить в подкаталог
    NN_not_kernel-AAA-BBB.

  - Патчи, помещённые в подкаталог NN_common, применяются в любом
    случае (эта возможность может использоваться для группировки
    патчей в нужном порядке).

3.1.2 Патчи с собственной программой для приложения
---------------------------------------------------

Если для применения патчей недостаточно возможностей стандартного
алгоритма, необходимые для этого действия должны выполняться скриптом
для /bin/sh, расположенным в каталоге /usr/src/kernel/patches/apply/;
имя файла должно совпадать с именем пакета патчей.

Apply-скрипт вызывается из каталога с исходными текстами ядра; ему
передаются следующие параметры:

  - $1 - имя каталога для патчей (/usr/src/kernel/patches);
  - $2 - имя пакета патчей;
  - $3 - версия ядра;
  - $4 - ветка ядра.

Если в процессе наложения патчей произошла ошибка, apply-скрипт должен
возвратить ненулевой код завершения.

При прикладывании патчей apply-скрипт может руководствоваться файлами
в подкаталоге исходных текстов ядра patches/ формата APPLIED_$name.
Существование таких файлов означает, что приложены патчи с именами
$name.  Скрипт не должен создавать файл APPLIED_$name со своим именем
в этом каталоге - этот файл создаётся стандартными функциями из
kernel-build-tools после успешного завершения apply-скрипта.

3.1.3 Макросы для spec-файлов пакетов с патчами
-----------------------------------------------

Поскольку пакет с патчами может включать большое число исходных
файлов, над которыми выполняются однотипные действия, в пакете
kernel-build-tools определены макросы %source и %install_patches,
позволяющие существенно сократить размер spec-файла таких пакетов.

Макрос %source следует использовать для перечисления файлов патчей
вместо встроенной конструкции SourceN: file в заголовке spec-файла:

%source <номер> <имя_файла> [<подкаталог>]

Помимо добавления указанного файла в список исходных файлов пакета
(Source<номер>: <имя_файла>), при этом указанное имя файла сохраняется
в списке файлов для последующей установки.  Кроме того, может быть
указан необязательный подкаталог для установки этого файла.

Далее в секции %install может использоваться макрос для установки
файлов, перечисленных в %source:

%install_patches

При выполнении этого макроса файлы, перечисленные в %source,
устанавливаются в каталог %patches_dir/%patch_name (макрос %patch_name
должен быть определён в spec-файле перед использованием
%install_patches).  Если для файла в %sources был указан подкаталог,
этот файл будет установлен в соответствующий подкаталог каталога
%patches_dir/%patch_name.

3.2 Пакет с исходными текстами.
--------------------------------

/usr/src/kernel/sources/<имя_пакета>-<версия>.tar.gz
или
/usr/src/kernel/sources/<имя_пакета>-<версия>.tar.bz2

3.3 Пакет с внешними модулями.
-------------------------------

/lib/modules/<версия ядра>-<flavour>/*
/usr/include/linux-<версия ядра>-<flavour>/include/*

3.4 Пакет с ядром.
------------------

image:
/boot/config-<версия ядра>-<flavour>-<release>
/boot/vmlinuz-<версия ядра>-<flavour>-<release>
/boot/System.map-<версия ядра>-<flavour>-<release>
/lib/modules/<версия ядра>-<flavour>-<release>/*

headers:
/usr/include/linux-<версия ядра>-<flavour>/*

headers-modules:
/usr/src/linux-<версия ядра>-<flavour>/*


4. Зависимости пакетов
----------------------

4.1 Пакеты с ядром
------------------

Для совместимости со старыми пакетами в пакетах kernel-image-* должны
быть указаны следующие зависимости:

Provides: kernel = %kversion
Provides: kernel24 = %kversion		(только для ядер 2.4.x)
Obsoletes: kernel-modules
Obsoletes: kernel-modules-i2c-%flavour

4.2 Пакеты с заголовками ядра
-----------------------------

Пакеты kernel-headers-<flavour> должны иметь следующие зависимости:

Requires: kernel-headers-common >= 1.1
Obsoletes: kernel-headers-i2c-%flavour
Provides: kernel-headers
Provides: kernel-headers-%base_flavour
Provides: kernel24-headers		(только для ядер 2.4.x)

Здесь %base_flavour - первая часть %flavour (без указания "-up" или
"-smp").

Пакеты kernel-headers-modules-<flavour> должны иметь зависимость на
соответствующий пакет kernel-headers-<flavour> с точным указанием
версии и сборки:

Requires: kernel-headers-%flavour = %version-%release

4.3 Пакеты с внешними модулями
------------------------------

Пакеты с модулями (kernel-modules-<набор_модулей>-<flavour>) должны
иметь зависимость PreReq на пакет ядра (kernel-image-<flavour>), для
которого они собраны, с точным указанием версии и сборки.

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

Кроме того, пакеты с модулями должны иметь зависимости вида:

Provides:  kernel-modules-%module_name-%kversion-%flavour-%krelease = %version-%release
Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease < %version-%release
Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease > %version-%release

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

4.4 Прочие пакеты
-----------------

Никакие пакеты, кроме kernel-modules-* и kernel-complete-*, не должны
иметь зависимостей на пакеты kernel-image-* и kernel-modules-* (как
прямых, так и косвенных через Provides в пакетах kernel-image-* и
kernel-modules-*).  В будущем это требование может быть ослаблено
после внесения в apt необходимой функциональности для правильной
обработки зависимостей на пакеты ядра.


5. Порядок приложения патчей при сборке по умолчанию.
-----------------------------------------------------

При построении исходных текстов для сборки spec ядра вызывает макрос
%apply_patches для приложения патчей, который содержится в пакете
kernel-build-tools.

Макрос %apply_patches вызывается следующим образом:

%apply_patches <ветка>

В параметре <ветка> должна быть указана часть версии ядра major.minor
(например, 2.4 или 2.6).

Для каждого пакета патчей, указанного в списке, макрос %apply_patches
проверяет наличие apply-скрипта, и при его наличии вызывает его для
применения патча.

При отсутствии apply-скрипта используется встроенный алгоритм
применения патчей.  Содержимое каталога
/usr/src/kernel/patches/<имя_пакета_патчей>/ обрабатывается в
алфавитном порядке (предполагается, что при сборке выставлено
LC_COLLATE=C).  Каждый элемент (файл или каталог) обрабатывается
следующим образом:

  1) Если в том же каталоге существует (пустой) файл с именем
     dont_apply_to_<версия_ядра>_<имя_файла>, элемент (файл или
     каталог) пропускается.

  2) Подкаталоги обрабатываются в зависимости от их имени (имя задаёт
     условия применения содержащихся в подкаталоге патчей).  Начальная
     часть имени, соответствующая маске ??_, игнорируется (это
     позволяет устанавливать порядок обработки подкаталогов путём
     добавления префиксов вида 10_).  Оставшаяся часть имени
     обрабатывается следующим образом:

       - common - патчи применяются в любом случае.
       - <ветка> - патчи применяются только к ядрам этой ветки.
       - apply_to_<версия_ядра> - патчи применяются только к указанной
         версии ядра.
       - <имя_пакета_патчей> - патчи применяются только в том случае,
         если в списке пакетов патчей для собираемого ядра есть
         указанный пакет.  Кроме того, если в этот момент указанный
         пакет патчей ещё не был применён (поскольку находится в
         списке патчей после текущего), он применяется немедленно (это
         важно в случае, когда патчи модифицируют одни и те же файлы).
       - not_<имя_пакета_патчей> - патчи применяются только в том
         случае, если в списке пакетов патчей для собираемого ядра нет
         указанного пакета.

     При выполнении условия алгоритм применяется рекурсивно к
     содержимому подкаталога.

  3) Обычные файлы используются в качестве входных файлов для
     программы patch; вызов patch производится с опцией -p1.

После успешного применения пакета патчей создаётся файл
patches/APPLIED_<имя_пакета_патчей>; наличие этого файла может быть
использовано в apply-скриптах для проверки, был ли применён ранее тот
или иной пакет патчей.


6. Переключение заголовочных файлов.
------------------------------------

После загрузки ссылки, на которые указывают /usr/include/{linux,asm},
направляются на заголовочные файлы, соответствующие текущему
ядру. Если последние отсутствуют, то ссылки перенаправляются на
заголовочные файлы из пакета glibc-kernheaders, лежащие в каталоге
/usr/include/linux-default.


7. Порядок принятия новых пакетов в Sisyphus.
---------------------------------------------

Дабы упорядочить вхождение новых пакетов в Sisyphus, сначала
разработчик обязан написать письмо в devel-kernel@altlinux.ru с темой
ITP: <имя_пакета> (Intent to package) и с description-ом пакета в теле,
чтобы пояснить, что новое он хочет добавить. Далее проходит обсуждение
этого пакета, и люди договариваются, целесообразно ли присутствие
пакета в Sisyphus. Kernel maintainer committee имеет право наложить
вето на вхождение пакета в Sisyphus при согласии всех участников KMC.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] [RFC] kernel-policy 1.2

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Mon, Jan 26, 2004 at 05:41:39PM +0300, Sergey Vlasov wrote:
> Пример spec-файла ядра пока удалён - он устарел, а текущие
> spec-файлы перед включением в policy в качестве примера
> нуждаются в чистке. :)

Эт точно, их даже cleanup_spec чистит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: [devel] [RFC] kernel-policy 1.2

[Ed V. Bartosh]

 SV> Пример spec-файла ядра пока удалён - он устарел, а текущие
 SV> spec-файлы перед включением в policy в качестве примера нуждаются в
 SV> чистке. :)

 SV> Прошу заинтересованных высказаться по этому поводу.

Я бы еще вот это добавил бы:
- описание kernel-complete наряду с остальными типами kernel- пакетов 
- как держать несколько разных версий kernel-modules по аналогии с kernel-sources, то
есть прямо в разделе "1.2 Внешние модули.".

-- 
Best regards,
Ed V. Bartosh