From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3F3A5D6E.2080804@altlinux.com> Date: Wed, 13 Aug 2003 19:46:54 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030710 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list References: <3F3A4052.5040905@altlinux.ru> <20030813141519.GT17550@osdn.org.ua> In-Reply-To: <20030813141519.GT17550@osdn.org.ua> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F4EF30466FFF2CED9BAF58C" Content-Transfer-Encoding: 8bit Cc: devel-kernel@altlinux.ru Subject: [d-kernel] Re: [devel] Re: HIMEM up X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 15:47:14 -0000 Archived-At: List-Archive: List-Post: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F4EF30466FFF2CED9BAF58C Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Michael Shigorin пишет: > 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). supermount я поддерживать отказываюсь в каком ли бо виде. Это не мультимедийно-столовое, а полное багов. Т.е. - для самоубийц. > > Так как политика развития aw определяется сугубо практическими > соображениями, то за него я спокоен в наибольшей мере. > > Соображений по части (не)вхождения/заголосовывания/выкидывания > патчей в std я пока не припомню, но это скорее именно что > ответственность майнтейнера с данными QA и support@ на руках. > > "mm" мне напоминает Костины ядра в части "работает на всем, но > иногда и на хорошем может странно себя вести" -- есть случаи, > когда лучше так, чем никак. > > _Возможно_, "ws" -- несколько более другая ветка, нежели mm -- в > той части, что акцент смещен все же не в фичи, а в стабильность, > но при этом есть вещи, которые могут быть просто не нужны на > "обычном" или "мультимедийном" столе -- вроде того же highmem или > поддержки стримеров. > > PS: есть и развитие темы по другому направлению -- сборки в > зависимости от архитектуры, которые учитывают бессмысленность > включения поддержки PS/2 или i440BX в athlon, KT400 -- в PIII или > ISA -- в P4 (?). Но это явно не в этом году :) > > PPS: мне показалось, что оригинальное письмо было в d-k@. > Перебираемся туда? Ага... мы сделали технологию размножения ядер... только не надо говорить: "Плодитесь", а сначала попробуйте собрать из incoming хотя-бы то, что залил туда Альберт (ну и естественно sisyphus_check на это). Дима предлагает сделать это Пете после нескольких неудачных попыток, а Петя загружен работой над std-up и std-smp ядрами. В общем - лично я против, пока по крайней мере не допилим CVS и не сделаем _автоматизированную_ сборку kernel-* пакетов. Rgds, Rider --------------enig7F4EF30466FFF2CED9BAF58C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Ol1zqohfd2vlwKsRAtWfAKCFjXSQ7HXF7YQYkmvllZBUnVAKkQCcC5P6 5WEjvN7lhK9+4DNB+3SIN+w= =tYm/ -----END PGP SIGNATURE----- --------------enig7F4EF30466FFF2CED9BAF58C--