Re: [devel] Re: HIMEM up

[Anton Farygin <rider@altlinux.com>]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]