Re: [d-kernel] kernel policy

[ed@altlinux.ru (Ed V. Bartosh)]

Hello, Anton

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

 AF> Удобство эксплуатации - безусловно, важный момент. А о
 AF> каком удобстве _эксплуатации_ может идти речь, если
 AF> вместо одного пакета появляется десяток-другой ?
Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
позволяет гибко комплектовать окончательные kernel-image с набором
нужных фич. А для юзера собственно ничего не меняется - он берет
понравившийся kernel-image и ставит себе. Не хочет задумываться -
берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
alsa и это не повод для вытягивания нового ядра, апгрэйдится только
один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
такого же плана ?

 AF> Пример: у меня есть некая железка, неизвестного
 AF> производителя. lspci сказал, что для нее неплохо было бы
 AF> использовать драйвер noname.o, которого в стандартном
 AF> ядре не оказалось. Вопрос - где искать этот драйвер?
В ядре, используемом для инсталяции и в std должно быть все железо. 
В терминах пакетов - все пакеты kernel-feat-drivers-...
Да и в остальных ядрах, кроме узкоспециализированных, заточеных под
конкретное железо, тоже. Тогда таких проблем не будет.

 AF> Т.е. - я к тому, что меняя инфраструктуру ядра нужно
 AF> позаботиться от том, что бы пользователи не получили
 AF> больших и неожиданных проблем, связанных с отсутствием
 AF> удобного средства установки необходимых ядерных пакетов.
Согласен, для этого мы это все здесь и обсуждаем.

 AF> Я бы предложил среднее: то, что необходимо для
 >> программы
 AF> установки (в плане функциональности) нам нужно включать в
 AF> kernel-image. Все остальное (например freeswan) -
 AF> выносить в отдельные пакеты. По мере появления
 AF> поставляемой из коробки функциональности (а также по мере
 AF> тестирования сторонних модулей) - переносить в базовое
 AF> ядро необходимые модули.
 >> Я бы не рассматривал здесь требования инсталлятора, неправильно это.
 >> Никто не мешает загрузить нужные модули и в процессе инсталляции.

 AF> Тогда нам соответственно нужна будет таблица аля
 AF> ldetect-lst, в которой будет прописано, в каких пакетах -
 AF> какие модули.
Не обязательно, если включить в ядро все железо. В виде зависимостей
на пакеты с драйверами, а не собирать с ядром. По возможности, конечно.

 AF> Необходимо будет поправить kudzu и инсталятор от MDK на
 AF> предмет использования этой таблицы при определении
 AF> устройств и установке пакетов.

 AF> kudzu придется править достаточно сильно.
А если гарантированно все пакеты с железом будут проставлены ?

 AF> ядра на модули. тяжело собирать, отслеживать зависимости,
 AF> устанавливать и многое другое.  Тогда уж лучше
 AF> реализовать мою идею с поставкой не упакованного в пакет
 AF> ядра и спец. скриптом, устанавливающим только необходимые
 AF> для данной машины модули.
 >> Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
 >> в пакет" ?

 AF> Все модули идут не в пакете, а просто в
 AF> архиве. Устанавливается не пакет, а конкретный модуль,
 AF> необходимый для поддержки устройства или
 AF> функциональности. Делается это достаточно простым
 AF> скриптом.
Все модули ? И каждый раз при обновлении какого-либо драйвера этот
архив пересобирать ? И ядро пересобирать ? 
И вытаскивать/устанавливать ?
И чем это лучше пересборки и установки одной
rpm-ки с нужными модулями ? Причем пересобирать ее будет ее
мэйнтейнер, а собиратель kernel-image только пропишет этот пакет
в 'Requires:'. Или я таки чего-то недопонимаю ?

-- 
Best regards,
Ed V. Bartosh