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> <3E9E6A76.6050402@altlinux.com> In-Reply-To: <3E9E6A76.6050402@altlinux.com> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 12:49:53 +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, 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