[d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 >> Можно рассмотреть 2 схемы:
 >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
 >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
 >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
 >> ставить только тот функционал, который нужен.
 >> Минусы тоже присутствуют, основной - большое количество
 >> пакетов,     ведь их нужно будет собирать под
 >> конкретные ядра.

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

 >> 2 - противоположная стратегия - сборка как можно большего количества
 >> модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
 >> плюсами все наоборот.

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

 >> И еще: Возможно было бы пойти по первой схеме, только
 >> иметь

 >> некое базовое собранное ядро (без фич, только с фиксами) и пакеты
 >> модулей, собранных относительно этой базы.
 >> А окончательные kernel-image будут просто пакетами, которые будут
 >> составлять некие наборы из базы и модулей.
 >> Возможно в этом случае удалось бы избежать основных
 >> недостатков схемы 1.
 >> Давайте обсудим, считаю, что это вопрос стратегический.

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

-- 
Best regards,
Ed V. Bartosh