From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 13 Aug 2003 17:15:19 +0300 From: Michael Shigorin To: devel@altlinux.ru Message-ID: <20030813141519.GT17550@osdn.org.ua> Mail-Followup-To: devel@altlinux.ru, devel-kernel@altlinux.ru References: <3F3A4052.5040905@altlinux.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+ZmrHH5cGjskQnY1" Content-Disposition: inline In-Reply-To: <3F3A4052.5040905@altlinux.ru> User-Agent: Mutt/1.4.1i Cc: devel-kernel@altlinux.ru Subject: [devel] Re: HIMEM up X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 14:15:21 -0000 Archived-At: List-Archive: List-Post: --+ZmrHH5cGjskQnY1 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote: > Существует-ли какая-либо обоснованная причина отсутствия > поддержки HIMEM в std-up ядре? Если не существует, или это > решаемо, то добавте пожалуйста CONFIG_HIGHMEM4G=y > Ставить SMP не предлагать ;-) > ps подобная просьба звучит периодически и в комьюнити и в сизифе Что характерно, там же звучит обоснование, почему _сейчас_ так уже не делается и почему предлагают ставить SMP или собирать свое. У меня другой вопрос -- нет ли у уважаемых kernel flavour maintainers видения того, какие ядра нужны? Пока предлагаю свои соображения: - std: default. То, что должно быть при отсутствии других соображений, штатным, поддерживаемым etc. То, что "в общем случае" должно просто работать. - aw: server default. Думаю, объяснять, что фокус сборки и поддержки серверного ядра достаточно сильно отличается от "общих" и тем более "столовых" соображений. - "mm"/"ws": нечто более мультимедийно-столовое, которое может позволить себе включать не очень проверенные драйверы нового железа, патчи вроде win4lin, lowlat, supermount или пяток версий NVIDIA, но зато работать на всем, что горит и быть более приемлемым решением вопроса, чем "соберите сами", по тем флангам, где "тенденция, однако" (как w4l или sm). Так как политика развития aw определяется сугубо практическими соображениями, то за него я спокоен в наибольшей мере. Соображений по части (не)вхождения/заголосовывания/выкидывания патчей в std я пока не припомню, но это скорее именно что ответственность майнтейнера с данными QA и support@ на руках. "mm" мне напоминает Костины ядра в части "работает на всем, но иногда и на хорошем может странно себя вести" -- есть случаи, когда лучше так, чем никак. _Возможно_, "ws" -- несколько более другая ветка, нежели mm -- в той части, что акцент смещен все же не в фичи, а в стабильность, но при этом есть вещи, которые могут быть просто не нужны на "обычном" или "мультимедийном" столе -- вроде того же highmem или поддержки стримеров. PS: есть и развитие темы по другому направлению -- сборки в зависимости от архитектуры, которые учитывают бессмысленность включения поддержки PS/2 или i440BX в athlon, KT400 -- в PIII или ISA -- в P4 (?). Но это явно не в этом году :) PPS: мне показалось, что оригинальное письмо было в d-k@. Перебираемся туда? -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --+ZmrHH5cGjskQnY1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/Okf3bsPDprYMm3IRAh5nAJ97r2Xy3aIGZ0n0H3XJPEqWoDmdeACgrE4I +IhApvCTUcxZbjBu/dDegQ0= =+p/C -----END PGP SIGNATURE----- --+ZmrHH5cGjskQnY1--