[d-kernel] Инструкция по сборке модулей ядра

[Михаил Якушин]

Konstantin A. Lepikhov wrote:
> Hi Михаил!
> 
> Friday 05, at 02:43:02 PM you wrote:
> 
>> На  altlinux.org выложена статья по сборке пакетов с модулями для наших 
>> ядер.
>> Конструктивная критика приветствуется.
>> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0
> Сразу что бросилось в глаза:
> 
> 1) Теперь о релизах пакетов с модулями. Поле release заполняется так:
> alt<module release>.<kernel version>.<kernel release>. 
> 
> - это придумано не просто так, а решает определенную проблему. Например
>   использование magic number в kernel version позволяет избежать
>   случайного вытеснения модуля собранного с более новым kernel-source но
>   старым template модулем собранным со старым kernel-source но новой
>   редакцией template. Прошу это учесть, а не просто принимать как
>   данность или придурь авторов.
Если не трудно, добавь пожалуйста.
> 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная
> (поскольку для понимания процесса сборки достаточно прочитать
> post-halloween документ про 2.6).
Что она может быть вредна, согласен, долго сомневался стоит ли её писать.
   Лучше расписать как собирать модули без
> использования hasher (см. старую документацию stanv@ на вики).
А там про хешер ничего не сказано.

> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
> собирать kernel-source на основе "следящего" бранча было бы здорово.
в смысле kernel-source большой? от ядра?
> 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно,
> поскольку нехватает i386 в начале вызова команды. 
В той версии buildmoudles которую я указал, setarch i586 прикручен 
внутрь. Это решает некоторые проблемы с некоторыми темплейтами.
> Опять же, забыта -m32 в
> случае сборки без hasher.
не думаю что кто-то будет собирать модуль без хешера под другую архитектуру.
> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними
> можно, только вот неясно с кем - т.е. надо расписать задачи kernel
> mainteiners team, чем она занимается, для чего нужна и как с ней
> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на
> неправильные действия (типа создать модуль, написать в Packager: KMT и
> потом KMT будет за это отдуваться).
Документировать ещё многое надо, я только начал.
> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :)
А что там по твоему должно быть написано?
> 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой.
> Наличие истории позволяет проследить тот длинный путь проб и ошибок +
> заглянуть в будущее.
Если не трудно, допиши.