From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 7 Mar 2002 18:17:04 +0300 From: Konstantin Volckov To: sisyphus@altlinux.ru Subject: Re: [sisyphus] Re[2]: Fwd: Re: [sisyphus] =?KOI8-R?B?ZXh0M87BIA==?= =?KOI8-R?B?y8/SzsXXz80g0sHaxMXMxQ==?= Message-Id: <20020307181704.6da503c9.goldhead@altlinux.ru> In-Reply-To: <200203070927.g279RJL30714@nefteprodukt.kr.ua> References: <20020306143404.44b57807.avl@l14.ru> <200203070658.g276wDEn025983@reks.ftc.ru> <20020307114617.63a0b6fd.avl@l14.ru> <200203070927.g279RJL30714@nefteprodukt.kr.ua> Organization: ALT Linux X-Mailer: Sylpheed version 0.7.2 (GTK+ 1.2.10; i586-alt-linux) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="sX34k_,=.MPzd.N4" Sender: sisyphus-admin@altlinux.ru Errors-To: sisyphus-admin@altlinux.ru X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: sisyphus@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: --sX34k_,=.MPzd.N4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit 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 --sX34k_,=.MPzd.N4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE8h4Ryt6s2zBR1r5IRAgKAAJ9/8SlUjcQPi+40zQktZEiixPRvowCfYLA3 VPhfpzW2dZSavoJeeNiOYEo= =tKjg -----END PGP SIGNATURE----- --sX34k_,=.MPzd.N4--