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... - это придумано не просто так, а решает определенную проблему. Например использование 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 на основе "следящего" бранча было бы здорово. 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, поскольку нехватает i386 в начале вызова команды. Опять же, забыта -m32 в случае сборки без hasher. 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними можно, только вот неясно с кем - т.е. надо расписать задачи kernel mainteiners team, чем она занимается, для чего нужна и как с ней взаимодействовать. Поскольку текущий текст вреден - он провоцирует на неправильные действия (типа создать модуль, написать в Packager: KMT и потом KMT будет за это отдуваться). 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. Наличие истории позволяет проследить тот длинный путь проб и ошибок + заглянуть в будущее. -- WBR et al.