[d-kernel] Re: HIMEM up

[d-kernel] Re: HIMEM up

[Michael Shigorin]

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

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 <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[d-kernel] Re: [devel] Re: HIMEM up

[Anton Farygin]

[-- 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 --]

Re: [d-kernel] Re: [devel] Re: HIMEM up

[Michael Shigorin]

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

On Wed, Aug 13, 2003 at 07:46:54PM +0400, Anton Farygin wrote:
> >У меня другой вопрос -- нет ли у уважаемых kernel flavour
> >maintainers видения того, какие ядра нужны?
[skip]

> supermount я поддерживать отказываюсь в каком ли бо виде.
> Это не мультимедийно-столовое, а полное багов. Т.е. - для самоубийц.

Мнению Сережи Рябчуна и Леши Морозова по этой теме я доверяю.

"Для самоубийц" по такой шкале глючности получаются AL[MJ]2.[02].

Тебя _заставлять_ поддерживать что-либо я не собираюсь -- это
было для других майнтейнеров.

Извини, что повторяюсь -- но если ты игнорируешь спрос и
обвиняешь других в том, где в пушку и сам -- у тебя серьезные
проблемы и с рынком, и с разработчиками (коллегами).

Жизнь такая.

> Ага... мы сделали технологию размножения ядер... только не надо
> говорить: "Плодитесь"

Да, разумеется.  Я ж и пытаюсь собрать _назад_ ветки вдоль
осмысленных (IMHO) направлений и не предлагаю всем немедленно
этим и заниматься.

-- 
Миша

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

Re: [d-kernel] Re: HIMEM up

[Ed V. Bartosh]

>>>>> "MS" == Michael Shigorin writes:

 MS>   On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote:
 >>  Существует-ли какая-либо обоснованная причина отсутствия
 >>  поддержки HIMEM в std-up ядре? Если не существует, или это
 >>  решаемо, то добавте пожалуйста CONFIG_HIGHMEM4G=y Ставить SMP не
 >>  предлагать ;-) ps подобная просьба звучит периодически и в
 >>  комьюнити и в сизифе
  
 MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
 MS>  уже не делается и почему предлагают ставить SMP или собирать
 MS>  свое.
А можно линк, я видимо пропустил.
  
 MS>  У меня другой вопрос -- нет ли у уважаемых kernel flavour
 MS>  maintainers видения того, какие ядра нужны?
  
 MS>  Пока предлагаю свои соображения:
  
 MS>  - std: default.  То, что должно быть при отсутствии других
 MS>    соображений, штатным, поддерживаемым etc.  То, что "в общем
 MS>    случае" должно просто работать.
  
 MS>  - aw: server default.  Думаю, объяснять, что фокус сборки и
 MS>    поддержки серверного ядра достаточно сильно отличается от
 MS>    "общих" и тем более "столовых" соображений.
Я уже прелагал, повторюсь - нужно это ядро переименовать в, скажем,
srv или что-нибудь другое более информативное.
  
 MS>  - "mm"/"ws": нечто более мультимедийно-столовое, которое может
 MS>    позволить себе включать не очень проверенные драйверы нового
 MS>    железа, патчи вроде win4lin, lowlat, supermount или пяток
 MS>    версий NVIDIA, но зато работать на всем, что горит и быть
 MS>    более приемлемым решением вопроса, чем "соберите сами", по тем
 MS>    флангам, где "тенденция, однако" (как w4l или sm).

А зачем ограничивать себя такими жесткими рамками ? 
Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то причины ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Ed V. Bartosh пишет:
>>>>>>"MS" == Michael Shigorin writes:
> 

<skip>

>   
>  MS>  - aw: server default.  Думаю, объяснять, что фокус сборки и
>  MS>    поддержки серверного ядра достаточно сильно отличается от
>  MS>    "общих" и тем более "столовых" соображений.
> Я уже прелагал, повторюсь - нужно это ядро переименовать в, скажем,
> srv или что-нибудь другое более информативное.

Ed, у меня тоже есть свои запросы к серверному ядру. Добавь в aw, 
пожалуйста, reiserfs - и я смогу начать его тестировать.

Rgds,
Rider

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

Re: [d-kernel] Re: HIMEM up

[Ed V. Bartosh]

>>>>> "AF" == Anton Farygin writes:

 >>     MS>  - aw: server default.  Думаю, объяснять, что фокус сборки
 >>     MS>  и
 >>   MS>    поддержки серверного ядра достаточно сильно отличается от
 >>   MS>    "общих" и тем более "столовых" соображений.
 >>  Я уже прелагал, повторюсь - нужно это ядро переименовать в,
 >>  скажем, srv или что-нибудь другое более информативное.
  
 AF>  Ed, у меня тоже есть свои запросы к серверному ядру. Добавь в
 AF>  aw, пожалуйста, reiserfs - и я смогу начать его тестировать.

Хорошо, добавлю. модулем. скоро.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Ed V. Bartosh пишет:
>>>>>>"AF" == Anton Farygin writes:
> 
> 
>  >>     MS>  - aw: server default.  Думаю, объяснять, что фокус сборки
>  >>     MS>  и
>  >>   MS>    поддержки серверного ядра достаточно сильно отличается от
>  >>   MS>    "общих" и тем более "столовых" соображений.
>  >>  Я уже прелагал, повторюсь - нужно это ядро переименовать в,
>  >>  скажем, srv или что-нибудь другое более информативное.
>   
>  AF>  Ed, у меня тоже есть свои запросы к серверному ядру. Добавь в
>  AF>  aw, пожалуйста, reiserfs - и я смогу начать его тестировать.
> 
> Хорошо, добавлю. модулем. скоро.

Спасибо. Попробую поставить на наши build сервера. Засад никаких нет ?

AMI megaraid работает ? (точнее - что я спрашиваю? если nidd наложил все 
патчи - гарантированно не работает)

Rgds,
Rider

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

Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Anton Farygin пишет:
> Ed V. Bartosh пишет:
> 
>>>>>>> "AF" == Anton Farygin writes:
>>
>>
>>
>>  >>     MS>  - aw: server default.  Думаю, объяснять, что фокус сборки
>>  >>     MS>  и
>>  >>   MS>    поддержки серверного ядра достаточно сильно отличается от
>>  >>   MS>    "общих" и тем более "столовых" соображений.
>>  >>  Я уже прелагал, повторюсь - нужно это ядро переименовать в,
>>  >>  скажем, srv или что-нибудь другое более информативное.
>>    AF>  Ed, у меня тоже есть свои запросы к серверному ядру. Добавь в
>>  AF>  aw, пожалуйста, reiserfs - и я смогу начать его тестировать.
>>
>> Хорошо, добавлю. модулем. скоро.
> 
> 
> Спасибо. Попробую поставить на наши build сервера. Засад никаких нет ?
> 
> AMI megaraid работает ? (точнее - что я спрашиваю? если nidd наложил все 
> патчи - гарантированно не работает)

Не работает эта железка:
AMI|PowerEdge RAID Controller 3/QC [STORAGE_RAID] (vendor:101e 
device:1960 subv:101e subd:0493)

Зацикливается при инициализации драйвера.

Rgds,
Rider

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

Re: [d-kernel] Re: HIMEM up

[Michael Shigorin]

On Thu, Aug 14, 2003 at 03:06:54PM +0400, Ed V. Bartosh wrote:
>  MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
>  MS>  уже не делается и почему предлагают ставить SMP или собирать
>  MS>  свое.
> А можно линк, я видимо пропустил.

Это в sisyphus@/community@.  SMP собирается с HIMEM.
Ссылку не дам -- без search.altlinux.ru и мне плохо ;-/

>  MS>  - aw: server default.  Думаю, объяснять, что фокус сборки и
> Я уже прелагал, повторюсь - нужно это ядро переименовать в,
> скажем, srv или что-нибудь другое более информативное.

Это не ко мне, хотя видимо. :)

>  MS>  - "mm"/"ws": нечто более мультимедийно-столовое, которое может
>  MS>    позволить себе включать не очень проверенные драйверы нового
>  MS>    железа, патчи вроде win4lin, lowlat, supermount или пяток
>  MS>    версий NVIDIA, но зато работать на всем, что горит и быть
>  MS>    более приемлемым решением вопроса, чем "соберите сами", по тем
>  MS>    флангам, где "тенденция, однако" (как w4l или sm).
> А зачем ограничивать себя такими жесткими рамками ? 

А кто сказал "ограничивать"? :)  Это скорее разграфка того, на
чем мне видится смысл концентрации усилий.  Экзотик-то много
может быть, но необязательно в Siysphus IMHO.

> Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
> причины ?

Чтобы облегчить еще и проблему выбора пользователям и их
администраторам.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Michael Shigorin пишет:
> On Thu, Aug 14, 2003 at 03:06:54PM +0400, Ed V. Bartosh wrote:
> 
>> MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
>> MS>  уже не делается и почему предлагают ставить SMP или собирать
>> MS>  свое.
>>А можно линк, я видимо пропустил.

<skip>
> 
>>Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
>>причины ?
> 
> 
> Чтобы облегчить еще и проблему выбора пользователям и их
> администраторам.
> 

Нет, что бы усложнить выбор пользователям. Всегда сложно сделать выбор, 
когда предложений слишком много ;-)

Особенно такой:

kernel-image-std-up
kernel-image-aw-up
kernel-image-w4l-up
kernel-image-llc-up

Можно к этому еще добавить (что бы окончательно запугать пользователя 
количеством ядер ;-) ):
kernel-image-dsa-up
kernel-image-rid-up
kernel-image-sup-up
kernel-image-svr-up
kernel-image-oem-up
kernel-image-dada-up
kernel-image-gmp-up
kernel-image-nbk-up
kernel-image-rsbac-up
kernel-image-owl-up

Выбор - мало не покажется  ;-)

Хотя я, в принципе, не возражаю - все равно std-up используется для 
дистрибутива для рабочей станции и инсталятора ;-)

Пока место есть на дисках - можно клепать.

Надо бы все-таки концепцию для ядер - сколько делать и зачем. Тогда 
будет более-менее понятно, какие ядра и для чего необходимо использовать.

Rgds,
Rider

P.S.
/me сделал :
  ls -al kernel-modules-*-std-up*|wc -l
      10
И умножил это на приведенный выше список ядер.... поплохело ;-)
140 пакетов с модулями ... при этом гарантированно не все пакеты с 
модулями будут для всех ядер.

P.P.S.
  /me вспомнил еще про smp и умножил на два ;-)))



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

Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Anton Farygin пишет:
> Michael Shigorin пишет:
<skip>
> 
> Rgds,
> Rider
> 
> P.S.
> /me сделал :
>  ls -al kernel-modules-*-std-up*|wc -l
>      10
> И умножил это на приведенный выше список ядер.... поплохело ;-)
> 140 пакетов с модулями ... при этом гарантированно не все пакеты с 
> модулями будут для всех ядер.
> 
> P.P.S.
>  /me вспомнил еще про smp и умножил на два ;-)))

P.P.S.

Пришел AEN, сказал про IA64, Athlon, AMD64, оптимизацию под пень 4 и мне 
поплохело еще в четыре раза, умноженное на smp ;-)

Шутка это конечно все, но в каждой шутке.. сами понимаете ;-)

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

[d-kernel] Re: HIMEM up

[Vitaly Ostanin]

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

On Thu, 14 Aug 2003 17:58:28 +0400
Anton Farygin <rider@altlinux.com> wrote:

<skipped/>

> > P.S.
> > /me сделал :
> >  ls -al kernel-modules-*-std-up*|wc -l
> >      10
> > И умножил это на приведенный выше список ядер.... поплохело
> > ;-) 140 пакетов с модулями ... при этом гарантированно не все
> > пакеты с модулями будут для всех ядер.
> > 
> > P.P.S.
> >  /me вспомнил еще про smp и умножил на два ;-)))
> 
> P.P.S.
> 
> Пришел AEN, сказал про IA64, Athlon, AMD64, оптимизацию под
> пень 4 и мне поплохело еще в четыре раза, умноженное на smp ;-)
> 
> Шутка это конечно все, но в каждой шутке.. сами понимаете ;-)

Да, слишком большая куча ядер наводит на мысли, что вся их
функциональность - взаимоисключающая :(

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [d-kernel] Re: HIMEM up

[Alexander Bokovoy]

On Thu, Aug 14, 2003 at 05:58:28PM +0400, Anton Farygin wrote:
> Anton Farygin пишет:
> >Michael Shigorin пишет:
> <skip>
> >
> >Rgds,
> >Rider
> >
> >P.S.
> >/me сделал :
> > ls -al kernel-modules-*-std-up*|wc -l
> >     10
> >И умножил это на приведенный выше список ядер.... поплохело ;-)
> >140 пакетов с модулями ... при этом гарантированно не все пакеты с 
> >модулями будут для всех ядер.
> >
> >P.P.S.
> > /me вспомнил еще про smp и умножил на два ;-)))
> 
> P.P.S.
> 
> Пришел AEN, сказал про IA64, Athlon, AMD64, оптимизацию под пень 4 и мне 
> поплохело еще в четыре раза, умноженное на smp ;-)
Ты думаешь, они все в одном репозитарии лежать будут? Размечтался, этого
бардака точно не допустим. :)


-- 
/ Alexander Bokovoy
So... did you ever wonder, do garbagemen take showers before they go to work?

Re: [d-kernel] Re: HIMEM up

[Michael Shigorin]

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

On Thu, Aug 14, 2003 at 05:51:30PM +0400, Anton Farygin wrote:
> >>Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
> >>причины ?
> >Чтобы облегчить еще и проблему выбора пользователям и их
> >администраторам.
> Нет, что бы усложнить выбор пользователям.

Погоди.  Чем?

> Всегда сложно сделать выбор, когда предложений слишком много
> ;-)

Я ж о чем и.

> Надо бы все-таки концепцию для ядер - сколько делать и зачем.

Отож бо.  И какие стоит помещать в sisyphus (критерии), а какие
-- нет.

> P.P.S.
>  /me вспомнил еще про smp и умножил на два ;-)))

$you помножь на {i[56]86,athlon} и забалдей... :-]

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [d-kernel] Re: HIMEM up

[Ed V. Bartosh]

>>>>> "MS" == Michael Shigorin writes:

 >>  А зачем ограничивать себя такими жесткими рамками ?
  
 MS>  А кто сказал "ограничивать"? :) Это скорее разграфка того, на
 MS>  чем мне видится смысл концентрации усилий.  Экзотик-то много
 MS>  может быть, но необязательно в Siysphus IMHO.
А по-моему наоборот, чем больше будет разных вариантов сборок, тем
больше народу будет ими охвачено, соответственно больше тестеров и
больше девелоперов, больше фиксов, фич. Чем плохо-то ?
Это не должно быть самоцелью, если какая-то фича отсутствует, то,
конечно, лучше вставить ее в существующее ядро, чем только ради этого
делать отдельное. Но потребности в данном случае разные бывают и
специально ограничивать набор ядер я бы не стал.
  
 >>  Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
 >>  причины ?
  
 MS>  Чтобы облегчить еще и проблему выбора пользователям и их
 MS>  администраторам.
Было бы из чего выбирать :)

-- 
Best regards,
Ed V. Bartosh