From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: Anton Farygin To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru> <3E9D746E.5040006@altlinux.ru> <3E9E4517.3070500@altlinux.com> In-Reply-To: <3E9E4517.3070500@altlinux.com> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 11:32:00 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: devel-kernel-admin@altlinux.ru Errors-To: devel-kernel-admin@altlinux.ru X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel-kernel@altlinux.ru List-Unsubscribe: , List-Id: ALT Linux kernel packages development List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: 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