From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9E6A76.6050402@altlinux.com> Date: Thu, 17 Apr 2003 12:48:54 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030210 X-Accept-Language: ru-ru, en MIME-Version: 1.0 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: X-Enigmail-Version: 0.70.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9AAFDAB2DE2D4D90CA059FE" 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9AAFDAB2DE2D4D90CA059FE Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Ed V. Bartosh пишет: > Hello, > > >> Можно рассмотреть 2 схемы: > >> 1 - стратегия выноса в отдельные пакеты как можно большего количества > >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще > >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и > >> ставить только тот функционал, который нужен. > >> Минусы тоже присутствуют, основной - большое количество > >> пакетов, ведь их нужно будет собирать под > >> конкретные ядра. > > AF> Еще один минус - придется увязывать названия пакетов с > AF> оборудованием и функционалом. Ибо для правильной > AF> установки этого в программе установки придется немного > AF> поработать. Сейчас же устанавливается ядро, в котором > AF> просто все есть. > Инсталлятор - это, конечно, важный элемент дистрибутива, но я бы не стал > привязываться к нему в данном вопросе. Гораздо важнее удобство > эксплуатации ядерных пакетов. Инсталлятор - это ведь только начало, да > и поправить его в нужную сторону проще, чем потом иметь проблемы с остальным. Удобство эксплуатации - безусловно, важный момент. А о каком удобстве _эксплуатации_ может идти речь, если вместо одного пакета появляется десяток-другой ? Пример: у меня есть некая железка, неизвестного производителя. lspci сказал, что для нее неплохо было бы использовать драйвер noname.o, которого в стандартном ядре не оказалось. Вопрос - где искать этот драйвер? Т.е. - я к тому, что меняя инфраструктуру ядра нужно позаботиться от том, что бы пользователи не получили больших и неожиданных проблем, связанных с отсутствием удобного средства установки необходимых ядерных пакетов. > > >> 2 - противоположная стратегия - сборка как можно большего количества > >> модулей вместе с ядром, в составе kernel-image. Здесь с минусами и > >> плюсами все наоборот. > > AF> Я бы предложил среднее: то, что необходимо для программы > AF> установки (в плане функциональности) нам нужно включать в > AF> kernel-image. Все остальное (например freeswan) - > AF> выносить в отдельные пакеты. По мере появления > AF> поставляемой из коробки функциональности (а также по мере > AF> тестирования сторонних модулей) - переносить в базовое > AF> ядро необходимые модули. > Я бы не рассматривал здесь требования инсталлятора, неправильно это. > Никто не мешает загрузить нужные модули и в процессе инсталляции. Тогда нам соответственно нужна будет таблица аля ldetect-lst, в которой будет прописано, в каких пакетах - какие модули. Необходимо будет поправить kudzu и инсталятор от MDK на предмет использования этой таблицы при определении устройств и установке пакетов. kudzu придется править достаточно сильно. > > >> И еще: Возможно было бы пойти по первой схеме, только > >> иметь > > >> некое базовое собранное ядро (без фич, только с фиксами) и пакеты > >> модулей, собранных относительно этой базы. > >> А окончательные kernel-image будут просто пакетами, которые будут > >> составлять некие наборы из базы и модулей. > >> Возможно в этом случае удалось бы избежать основных > >> недостатков схемы 1. > >> Давайте обсудим, считаю, что это вопрос стратегический. > > AF> мне если честно не очень нравится идея сильного дробления > AF> ядра на модули. тяжело собирать, отслеживать зависимости, > AF> устанавливать и многое другое. Тогда уж лучше > AF> реализовать мою идею с поставкой не упакованного в пакет > AF> ядра и спец. скриптом, устанавливающим только необходимые > AF> для данной машины модули. > Поясни, плз, поподробнее, я недопонял. Как это "не упакованного > в пакет" ? Все модули идут не в пакете, а просто в архиве. Устанавливается не пакет, а конкретный модуль, необходимый для поддержки устройства или функциональности. Делается это достаточно простым скриптом. Rgds, Rider P.S. Просьба не забывать о готовящейся версии Junior 2.3 --------------enigC9AAFDAB2DE2D4D90CA059FE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+nmp6qohfd2vlwKsRAvn/AJ990RnXAryzYk4w3g/r3zz/KU5tRwCdGPTE Ry+eg2bawgRZYmE0yERpUy8= =MNvF -----END PGP SIGNATURE----- --------------enigC9AAFDAB2DE2D4D90CA059FE--