On Thu, 7 Mar 2002 11:30:39 +0200 Serge Polkovnikov wrote: > Чет 07 Бер 2002 10:46 Ви написали: Hi! > > подход Волковова логичен и системен - все модули в модули. > Но опрадывает ли себя такой подход, если он во многих случаях не > функционален > > > другой подход - сколько конфигураций, столько и ядер. > > третий состоит в том, чтобы оптимизировать второй подход. > Возможно это более приемлемые варианты. Например какой-нибудь домашний - > красивый (со всякими там fb) и например серверный. > > > ваш подход просто наивен  - "лишние 100к ядро не раздуют" > Может я ошибаюсь, но я не вижу большой беды в том что ядро будет > на 100 КБ больше или даже на 2 МБ. В условиях когда какой-то kicker > занимает в памяти 13 МБ, экономить сотню килобайт в ядре... > И если уж была влючена в ядро поддержка lpp, то я думаю было бы логичным > сделать, что бы эту поддержку можно было реально использовать. Во-первых, память, занятая неиспользуемыми драйверами в ядре _не_ освобождается в процессе работы - т.е. без пересборки ядра эту проблему решить нельзя (А тот же kicker можно просто не использовать). Во-вторых, касательно lpp - эта фича рассчитана исключительно на наивных юзверей, броских на интересные эффекты (т.е. тех, у кого включен 5-й runlevel и кто не понимает полезности вывода отладочной информации в процессе загрузки ядра и скриптов, поэтому они беспредельно счастливы видеть заставочную картинку a'la mustdie). Так что lpp реально используется - но только для той категории пользователей, кому оно нужно. Если же пользователь реально использует в своей работе консоль - то ему по-моему эта заставка реально нафиг не нужна - он ее выключает, настраивает под себя framebuffer (например для matrox или radeon) и работает нормально, без картинки. Размер памяти, занимаемой ядром, эта картинка не увеличивает, т.к. она убивается в ядре сразу после его загрузки - при выключении системы она подзагружается из модуля fblogo. То есть как обычно возникла ситуация - либо красивости - либо функциональность и, как мне кажется, удалось нормально разрешить это противоречие, обеспечив хорошую фукнциональность и наличие возможностей в обоих случаях. > И обеспечить наличие в ядре того, что может понадобиться *именно в > процессе загрузки* было бы неплохим подходом. Оно так и делается - конкретно чего сейчас жизненно не хватает в ядре в процессе его загрузки (и что не может быть загружено модулем из initrd)? > С уважением > Сергей Полковников -- Успехов, Konstantin