[d-kernel] kernel policy

[Peter Novodvorsky]

Эд, привет.

ed на sam-solutions.net (Ed V. Bartosh) writes:

> Дык feat и fix будут говорить о том, что это патч, если уж так оно
> надо. Только зачем, никак не пойму. Какая от этого польза знать что
> это патч ? Давайте абстрагироваться :) Я вижу пакет
> kernel-feat-security-rsback - мне обязательно знать, что это патч ?
> Зачем ?

Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external
модулями типа kernel-alsa и kernel-drm.

> По-моему сейчас строится новая схема сборки. И существующие
> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
> такие ядра есть в Сизифе :) Где развитие ?
> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
> представляется слабым доказательством.

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

>  PN> secfixes. будут выглядеть именно так.
> Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ?
> Нужно определить формат, как в случае с kernel-image, например.

Нет. secfixes будут выглядеть как kernel-fix-security. А ide фиксы
будут выглядеть как kernel-fix-ide.

>  PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
>  PN> разбирается скрипт apply.
> Ты сам себе протифоречишь:

Я имел ввиду, то как пакет с патчами распологает свои файлы внутри его
каталога, -- не дело полиси.

> Если не определить, где патчи будут хранить нужные им файлы - будет
> путаница. А смысл ?

С внешней стороны путаницы не будет, так как всем этим будет управлять
программа apply.

>  PN> Нет, не опциальная. Если нужно, -- можно сделать
>  PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто
>  PN> соурсить этот файл.
> Можно, конечно и так. Мне показалось более элегантным решить это с
> помощью макроса. Давай я тебе его пришлю, а то так трудно
> разговаривать ?

Давай.

>  PN> В среднем, будет один и тот же алгоритм. Но надо оставить за
>  PN> патче-пакето-твроителями полную свободу в том, как и что патчить. 
> Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит.

Главное, что внешний интерфейс фиксирован: программа apply. А то как
она действует, -- это дело разработчика. Можно написать helper,
который будут соурсить большинство apply скриптов.

> Что плохого в том, что при взгляде в каталог с патчами будет виден
> порядок их приложения ?

Если патч сделан грамотно, он и так будет виден. Это логично. Но
свободу реализации при условии сохранения интерфейса за разработчиком
оставлять надо.

>  PN> Нужно. Почему не нужно?
> Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES
> и флажок ./patches/APPLIED_имя пакета дублируют друг друга.

Да.

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

Согласен.

>  >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
>  >> устанавливаются в /usr/src/kernel/patches/название_пакета/
>
>  PN> Это не регулируется policy.
> Дык и напрасно :) Собственно, это только мои предложения, решать
> тебе.

У меня есть намерение, если ты не против, включить тебя в kernel
maintainer committee, когда ты станешь разработчиком, так что решать
таки *нам*.

> Согласен. Пусть будет рекомендательный. Это только первый шаг к 
> условному приложению патчей. Мне порекомендовали, например, взглянуть
> на PATCH-O-MATIC, там есть на что посмотреть в этом плане.
> Может быть и есть смысл попользоваться их схемой.

А PATCH-O-MATIC требует своего вида apply скриптов. Я и веду к тому,
что всё должно регулироваться внутри пакета.

>
>  >> 4. При условии успешного приложения пакета патчей в каталоге ./patches
>  >> соответствующего дерева kernel sources должен создаваться файл
>  >> APPLIED_имя_пакета
>
>  PN> Это рекоммендация.
> См. выше.

Предлагаю писать номер строчки или её обозначение в таких случаях. Но
я и так понял.

>  PN> это рекоммендация.
> Но, согласись, при такой схеме гораздо проще выяснить с какими файлами
> работает пакет. Почему бы ее и не применять ?

Потому, что если пэкэджер хороший, он сделает так, чтобы было просто
выяснить. А плохих у нас нет. :) И не будет.

>  PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
>  PN> из apply-скриптов.
> Я не против, в принципе. Но почему тебе так не нравится идея с
> макросом ? Принципиальной разницы нет, IMHO.

См. ниже [1].

>
>  >> 7. Нестандартная действия по установке/приложению патчей производятся
>  >> в скриптах имя_пакета-apply и устанавливаются в
>  >> /usr/src/kernel/patches/apply
>
>  PN> Не понимаю. Зачем делать условный оператор?
> Чтобы избавиться в большинстве случаев от apply скриптов.

[1]. Чем так помешали apply скрипты? apply скрипт, -- это интерфейс
доступа к патчу. И он фиксирован. Делать в таких случаях условный
оператор не очень красиво.



-- 
Peter Novodvorsky                             nidd на myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!