From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 26 Jan 2004 17:41:39 +0300 From: Sergey Vlasov To: devel-kernel@altlinux.ru Message-ID: <20040126144139.GD32065@master.mivlgu.local> Mail-Followup-To: devel-kernel@altlinux.ru, devel@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JBi0ZxuS5uaEhkUZ" Content-Disposition: inline Cc: devel@altlinux.ru Subject: [devel] [RFC] kernel-policy 1.2 X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 14:41:40 -0000 Archived-At: List-Archive: List-Post: --JBi0ZxuS5uaEhkUZ Content-Type: multipart/mixed; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline Content-Transfer-Encoding: 8bit --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello! На обсуждение выносится исправленная и дополненная редакция kernel-policy. Изменений достаточно много: - Добавлено описание средств для условного применения патчей (часть этих возможностей уже была в kernel-build-tools, но без документации; часть была добавлена в процессе работы над ядрами 2.6.x). - Добавлено описание макросов для пакетов с патчами (%source и %install_patches). - Добавлены требования к зависимостям пакетов. Возможно, часть зависимостей для совместимости в действительности лишняя (у меня есть сомнения по поводу Obsoletes: kernel-modules-i2c-%flavour - подозреваю, что при этом происходит не то, что имели в виду). Пример spec-файла ядра пока удалён - он устарел, а текущие spec-файлы перед включением в policy в качестве примера нуждаются в чистке. :) Прошу заинтересованных высказаться по этому поводу. -- Sergey Vlasov --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="kernel-policy.txt" Content-Transfer-Encoding: 8bit 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-<сокращённое название набора модулей>-. Пакеты с заголовочными файлами этих модулей должны называться kernel-headers-<сокращённое название набора модулей>-. Такие пакеты могут и не существовать, они требуются лишь в том случае, когда эти заголовочные файлы требуются для утилит или других модулей. 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-. Пакеты с заголовочными файлами ядра должны называться kernel-headers-. Пакеты с внутренними заголовочными файлами ядра, которые необходимы только для сборки модулей для этого ядра (например, внутренние заголовки подсистемы SCSI), должны называться kernel-headers-modules-. 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/<версия ядра>-/* /usr/include/linux-<версия ядра>-/include/* 3.4 Пакет с ядром. ------------------ image: /boot/config-<версия ядра>-- /boot/vmlinuz-<версия ядра>-- /boot/System.map-<версия ядра>-- /lib/modules/<версия ядра>--/* headers: /usr/include/linux-<версия ядра>-/* headers-modules: /usr/src/linux-<версия ядра>-/* 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- должны иметь следующие зависимости: 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- должны иметь зависимость на соответствующий пакет kernel-headers- с точным указанием версии и сборки: Requires: kernel-headers-%flavour = %version-%release 4.3 Пакеты с внешними модулями ------------------------------ Пакеты с модулями (kernel-modules-<набор_модулей>-) должны иметь зависимость PreReq на пакет ядра (kernel-image-), для которого они собраны, с точным указанием версии и сборки. При наличии зависимостей между модулями, содержащимися в разных пакетах, должны присутствовать соответствующие зависимости (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. --a2FkP9tdjPU2nyhF-- --JBi0ZxuS5uaEhkUZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFScjW82GfkQfsqIRAqRoAJ9ANv9azPTH6k14+KaoYuk0WBIl9ACfSEwT w76ok8UfoaZHoMPhkN0Q+aE= =x0ky -----END PGP SIGNATURE----- --JBi0ZxuS5uaEhkUZ--