[d-kernel] Daedalus kernel

[d-kernel] Daedalus kernel

[Ed V. Bartosh]

Hello,

Можно ли узнать попродробнее о новой схеме сборки ядер, которая
обозначена сейчас в Daedalus-е ?

Интересуют следующие вещи:

1. какие категории патчей будут присутствовать в виде отдельных пакетов
   (пока есть только secfixes, насколько я понимаю)

2. будут ли патчи для железа входить в пакет kernel-source или
   все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
   по типам устройств ?

3. Какие kernel-images планируются к сборке в первую очередь и когда ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[aen]

Ed V. Bartosh пишет:

>Hello,
>
>Можно ли узнать попродробнее о новой схеме сборки ядер, которая
>обозначена сейчас в Daedalus-е ?
>
Смотрите в Сизифе, там уже первый вариант ядра up.

>  
>
Rgrds, Алексей

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

 >> 1. какие категории патчей будут присутствовать в виде отдельных
 >> пакетов

 >> (пока есть только secfixes, насколько я понимаю)

 AF> Вообще вчера в Sisyphus ушла пачка пакетов с патчами для ядра -
 AF> смотрите там. (www.altlinux.ru -> Sisyphus)
Спасибо, посмотрел. 
Я собственно и задавал этот вопрос , чтобы прояснить ситуацию с
принципами категоризации патчей, пока этот принцип не совсем для меня прояснился.

Вот, например kernel-patch-qlogic - это, IMHO, слишком мелкое
разбиение, я бы так не делал. Иначе эта схема слишком разбухнет,
трудно будет сопровождать. kernel-patch-driver-scsi или что-нибудь
такое, где будут все scsi-ориентированные патчи мне кажется более
правильной.

Было бы неплохо прямо сейчас наметить/обсудить категории патчей, как
считаете ?

 >> 2. будут ли патчи для железа входить в пакет kernel-source или

 >> все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
 >> по типам устройств ?

 AF> Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет
 AF> (почти) на работу всего остального ядра.
Не согласен. Зачем тащить в базовый пакет то, что может быть не нужно
для сборки некоторых ядер ? Принцип сборки нарушим.
Я бы, например, и тот патч, который есть(aic7xx-makefile) вынес в
отдельную категорию. Опять таки для соответствия принципу.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

 >> Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет
 >> (почти) на работу всего остального ядра.

 a> Я думаю, что нельзя ломать концепцию. Можно объединить все "железные"
 a> патчи в один пакет, можно разбить их по группам, но не вносить в
 a> kernel-source.
Поддерживаю.

 >>> 3. Какие kernel-images планируются к сборке в первую очередь и когда ?
 >> 
 >> 
 >> kernel-up и kernel-vanilla уже собраны.

 a> kernel-up пока не содержит ряда обязательных features (Crypto API,
 a> FreeSWAN etc.). Насколько я понимаю, они в TODO к релизу 2.4.21.
Там в общем-то много чего нет, это же только начало.
FreeSWAN и типа этого - это макроуровень так сказать. 
На уровне пониже фиксов к железу нет пока, acpi нет (или не
планируется ?) 
и т.д.

Еще вопрос по поводу концепции: Каков принцип разрешения конфликтов
между патчами ?
Дело в том, что хотелось бы получить возможность собирать на основании
альтовской базы и другие ядра, но не прикладывая некоторые группы
патчей есть угроза получить реджекты. Предусматриваются ли меры для
придания схеме гибкости еще и в этом направлении ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hello,
> 
> Можно ли узнать попродробнее о новой схеме сборки ядер, которая
> обозначена сейчас в Daedalus-е ?
> 
> Интересуют следующие вещи:
> 
> 1. какие категории патчей будут присутствовать в виде отдельных пакетов
>    (пока есть только secfixes, насколько я понимаю)

Вообще вчера в Sisyphus ушла пачка пакетов с патчами для ядра - смотрите 
там. (www.altlinux.ru -> Sisyphus)


> 
> 2. будут ли патчи для железа входить в пакет kernel-source или
>    все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
>    по типам устройств ?

Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет 
(почти) на работу всего остального ядра.

> 
> 3. Какие kernel-images планируются к сборке в первую очередь и когда ?

kernel-up и kernel-vanilla уже собраны.


Rgds,
Rider

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

Re: [d-kernel] Daedalus kernel

[Alexander Bokovoy]

On Tue, Apr 08, 2003 at 04:38:43PM +0400, Anton Farygin wrote:
> >Hello,
> >
> >Можно ли узнать попродробнее о новой схеме сборки ядер, которая
> >обозначена сейчас в Daedalus-е ?
> >
> >Интересуют следующие вещи:
> >
> >1. какие категории патчей будут присутствовать в виде отдельных пакетов
> >   (пока есть только secfixes, насколько я понимаю)
> 
> Вообще вчера в Sisyphus ушла пачка пакетов с патчами для ядра - смотрите 
> там. (www.altlinux.ru -> Sisyphus)
kernel-patch-evms-1.9.2-alt1 
   Необходимо откатить версию EVMS на 1.2.1. Все остальное пока
   нестабильно и вызывает большое число нареканий в списках рассылки EVMS.
   Напомню, что мы (ApplianceWare) "живем" на EVMS уже около года и имеем
   определенный опыт борьбы с ним.

-- 
/ Alexander Bokovoy
---
People will buy anything that's one to a customer.

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

 AF> Вот такое разбиение, например, для начала:

 AF> kernel-patches-new-drivers - содержит новые драйвера
 AF> kernel-patches-bugfixes-drivers - содержит исправления для
 AF> существующих драйверов

 AF> kernel-patches-security - включает в себя secrurity-fixes
 AF> kernel-patches-update-drivers - содержит в себе обновления для
 AF> драйверов до новых версий.

 AF> далее по такому-же принципу ;-)

 AF> Т.е. - бить или нет по категориям я бы не стал. По моему с железом все
 AF> достаточно прозрачно и если патч не вносит изменения никуда, кроме
 AF> кода самого драйвера - то его вполне можно включать всегда.
Зачем так зажимать схему ? Это вариант, противоположный вынесению
каждого патча в отдельный пакет. Я считаю, что нужен компромисс, то
есть в данном случае все-таки группировка по категориям.
Если мне, например, не нужны патчи, касающиеся видео, или, скажем
ide, то я и не буду их прикладывать. Тем более, что частенько они
правят не только свой код.
Мне кажется, что некая гибкость в этом деле не помешает.

Предлагаю для железных патчей категории по принципу схемы 
каталогов в сорцах:
kernel-patches-drivers-net
kernel-patches-drivers-scsi
kernel-patches-drivers-ide
kernel-patches-net
kernel-patches-fs

И подкатегории fixes, updates, new, как Вы предлагаете.

Точно так же можно поступить и с остальными, зачем велосипед
изобретать, если в ядре уже есть устоявшаяся иерархия.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Anton Farygin]

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

aen пишет:
> Anton Farygin пишет:
> 
>> Ed V. Bartosh пишет:
>>
>>> Hello,
>>>
>>> Можно ли узнать попродробнее о новой схеме сборки ядер, которая
>>> обозначена сейчас в Daedalus-е ?
>>>
>>>
>>> 2. будут ли патчи для железа входить в пакет kernel-source или
>>>    все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
>>>    по типам устройств ?
>>
>>
>>
>> Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет 
>> (почти) на работу всего остального ядра. 
> 
> 
> Я думаю, что нельзя ломать концепцию. Можно объединить все "железные" 
> патчи в один пакет, можно разбить их по группам, но не вносить в 
> kernel-source.

Да, я не правильно выразился. Речь о том, что бы сделать накладывание 
железных патчей на ядра с максимальным приоритетом. vanilla можно 
собирать так-же с железными патчами.


Rgds,
Rider

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

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

 >> Я бы, например, и тот патч, который есть(aic7xx-makefile) вынес в
 >> отдельную категорию. Опять таки для соответствия принципу.

 DVL> Тогда эта категория будет называться kernel-patch-build, поскольку
 DVL> aic7xx-makefile - это исправление makefile, чтобы aic7xx вообще собирался
 DVL> в нашей среде разработки.
Угу, одобрямс. 
Я понял зачем этот патч :) 
Просто нельзя егго в kernel-source, там только vanilla должна быть,
IMHO. Тогда этот пакет приобретает нужную степень гибкости :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Sisyphus kernel

[Dmitry V. Levin]

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

On Tue, Apr 08, 2003 at 05:02:54PM +0400, Anton Farygin wrote:
> >>>2. будут ли патчи для железа входить в пакет kernel-source или
> >>>   все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
> >>>   по типам устройств ?
> >>
> >>Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет 
> >>(почти) на работу всего остального ядра. 
> >
> >Я думаю, что нельзя ломать концепцию. Можно объединить все "железные" 
> >патчи в один пакет, можно разбить их по группам, но не вносить в 
> >kernel-source.
> 
> Да, я не правильно выразился. Речь о том, что бы сделать накладывание 
> железных патчей на ядра с максимальным приоритетом. vanilla можно 

Нет.
С максимальным приоритетом должны быть critical bugfixes.

> собирать так-же с железными патчами.

Нет, vanilla - это vanilla.
Никаких патчей, кроме critical bugfixes.


--
ldv

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

Re: [d-kernel] Sisyphus kernel

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Tue, Apr 08, 2003 at 05:02:54PM +0400, Anton Farygin wrote:
> 
>>>>>2. будут ли патчи для железа входить в пакет kernel-source или
>>>>>  все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
>>>>>  по типам устройств ?
>>>>
>>>>Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет 
>>>>(почти) на работу всего остального ядра. 
>>>
>>>Я думаю, что нельзя ломать концепцию. Можно объединить все "железные" 
>>>патчи в один пакет, можно разбить их по группам, но не вносить в 
>>>kernel-source.
>>
>>Да, я не правильно выразился. Речь о том, что бы сделать накладывание 
>>железных патчей на ядра с максимальным приоритетом. vanilla можно 
> 
> 
> Нет.
> С максимальным приоритетом должны быть critical bugfixes.
> 
> 
>>собирать так-же с железными патчами.
> 
> 
> Нет, vanilla - это vanilla.
> Никаких патчей, кроме critical bugfixes.

А что такое critical bugfixes ?

Является ли неработоспособность какой-то железки critical ?

Rgds,
Rider



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

Re: [d-kernel] Daedalus kernel

[aen]

Anton Farygin пишет:

> Ed V. Bartosh пишет:
>
>> Hello,
>>
>> Можно ли узнать попродробнее о новой схеме сборки ядер, которая
>> обозначена сейчас в Daedalus-е ?
>>
>>
>> 2. будут ли патчи для железа входить в пакет kernel-source или
>>    все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
>>    по типам устройств ?
>
>
> Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет 
> (почти) на работу всего остального ядра. 

Я думаю, что нельзя ломать концепцию. Можно объединить все "железные" 
патчи в один пакет, можно разбить их по группам, но не вносить в 
kernel-source.

>
>
>>
>> 3. Какие kernel-images планируются к сборке в первую очередь и когда ?
>
>
> kernel-up и kernel-vanilla уже собраны. 

kernel-up пока не содержит ряда обязательных features (Crypto API, 
FreeSWAN etc.). Насколько я понимаю, они в TODO к релизу 2.4.21.

Rgrds, AEN

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

 >> Точно так же можно поступить и с остальными, зачем
 >> велосипед
 >> изобретать, если в ядре уже есть устоявшаяся иерархия.

 AF> Хм... наверное это правильно - идти по иерархии в ядре, но
 AF> как быть с особо тяжелыми случаями, когда необходимо
 AF> наложить часть патчей на scsi и часть патчей на net ?

 AF> Или особо тяжелые случаи - в морг ? ;-)
Можно и в морг, а можно, скажем, разбить такой патч на несколько и
положить в разные категории :)
В любом случае без исключений не обойтись, это понятно. Ну если уж
никак, то положится такой патч отдельно, ничего страшного.
Когда основная часть будет нормально раложена по категориям, то
ориентироваться в такой схеме будет проще, я думаю.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Anton Farygin]

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

Ed V. Bartosh пишет:
>  >> 1. какие категории патчей будут присутствовать в виде отдельных
>  >> пакетов
> 
>  >> (пока есть только secfixes, насколько я понимаю)
> 
>  AF> Вообще вчера в Sisyphus ушла пачка пакетов с патчами для ядра -
>  AF> смотрите там. (www.altlinux.ru -> Sisyphus)
> Спасибо, посмотрел. 
> Я собственно и задавал этот вопрос , чтобы прояснить ситуацию с
> принципами категоризации патчей, пока этот принцип не совсем для меня прояснился.
> 
> Вот, например kernel-patch-qlogic - это, IMHO, слишком мелкое
> разбиение, я бы так не делал. Иначе эта схема слишком разбухнет,
> трудно будет сопровождать. kernel-patch-driver-scsi или что-нибудь
> такое, где будут все scsi-ориентированные патчи мне кажется более
> правильной.
> 
> Было бы неплохо прямо сейчас наметить/обсудить категории патчей, как
> считаете ?

да, конечно.

> 
>  >> 2. будут ли патчи для железа входить в пакет kernel-source или
> 
>  >> все-таки лучше их вынести в отдельные пакеты, сгруппировав, скажем,
>  >> по типам устройств ?
> 
>  AF> Я бы все-таки в kernel-source их внес. Это крайне важно и не влияет
>  AF> (почти) на работу всего остального ядра.
> Не согласен. Зачем тащить в базовый пакет то, что может быть не нужно
> для сборки некоторых ядер ? Принцип сборки нарушим.
> Я бы, например, и тот патч, который есть(aic7xx-makefile) вынес в
> отдельную категорию. Опять таки для соответствия принципу.

Я имел в виду не в базовый ;-)

Вот такое разбиение, например, для начала:

kernel-patches-new-drivers - содержит новые драйвера
kernel-patches-bugfixes-drivers - содержит исправления для существующих 
драйверов
kernel-patches-security - включает в себя secrurity-fixes
kernel-patches-update-drivers - содержит в себе обновления для драйверов 
до новых версий.

далее по такому-же принципу ;-)

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

Rgds,
Rider



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

Re: [d-kernel] Sisyphus kernel

[Anton Farygin]

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

aen пишет:
> Anton Farygin пишет:
> 
>>
>> А что такое critical bugfixes ?
>>
>> Является ли неработоспособность какой-то железки critical ?
> 
> 
> Для vanilla -- думаю, что нет.  В конце концов, мы собираем up -- оно 
> наше основное ядро, а не vanilla.

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

Rgds,
Rider



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

Re: [d-kernel] Sisyphus kernel

[Dmitry V. Levin]

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

On Tue, Apr 08, 2003 at 05:19:04PM +0400, Anton Farygin wrote:
> >Нет, vanilla - это vanilla.
> >Никаких патчей, кроме critical bugfixes.
> 
> А что такое critical bugfixes ?
> 
> Является ли неработоспособность какой-то железки critical ?

Как насчёт такого правила:

critical bugfixes - это такие bugfixes, при наличии которых мы выпускаем
update.

Обоснование: зачастую добавление поддержки новой железки выводит из строя
поддержку других железок.


--
ldv

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

Re: [d-kernel] Sisyphus kernel

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Tue, Apr 08, 2003 at 05:19:04PM +0400, Anton Farygin wrote:
> 
>>>Нет, vanilla - это vanilla.
>>>Никаких патчей, кроме critical bugfixes.
>>
>>А что такое critical bugfixes ?
>>
>>Является ли неработоспособность какой-то железки critical ?
> 
> 
> Как насчёт такого правила:
> 
> critical bugfixes - это такие bugfixes, при наличии которых мы выпускаем
> update.

Добро.

> 
> Обоснование: зачастую добавление поддержки новой железки выводит из строя
> поддержку других железок.

Нет, неправильное обоснование. Правильно у AEN'а ;-)

Добавление поддержки новой железки крайне редко выводит из строя 
поддержку других железок. Разве что поддержка новой железки добавляется 
в виде обновления драйвера до более новой, непроверенной версии.

ну а вообще речь идет про vanilla kernel.

Rgds,
Rider

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

Re: [d-kernel] Daedalus kernel

[Dmitry V. Levin]

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

On Tue, Apr 08, 2003 at 04:19:04PM +0400, Ed V. Bartosh wrote:
> Я собственно и задавал этот вопрос , чтобы прояснить ситуацию с
> принципами категоризации патчей, пока этот принцип не совсем для меня прояснился.
> 
> Вот, например kernel-patch-qlogic - это, IMHO, слишком мелкое
> разбиение, я бы так не делал. Иначе эта схема слишком разбухнет,
> трудно будет сопровождать. kernel-patch-driver-scsi или что-нибудь
> такое, где будут все scsi-ориентированные патчи мне кажется более
> правильной.
> 
> Было бы неплохо прямо сейчас наметить/обсудить категории патчей, как
> считаете ?

Определенно откладывать не стоит.

> Я бы, например, и тот патч, который есть(aic7xx-makefile) вынес в
> отдельную категорию. Опять таки для соответствия принципу.

Тогда эта категория будет называться kernel-patch-build, поскольку
aic7xx-makefile - это исправление makefile, чтобы aic7xx вообще собирался
в нашей среде разработки.


--
ldv

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

Re: [d-kernel] Sisyphus kernel

[aen]

Anton Farygin пишет:

>
> А что такое critical bugfixes ?
>
> Является ли неработоспособность какой-то железки critical ?

Для vanilla -- думаю, что нет.  В конце концов, мы собираем up -- оно 
наше основное ядро, а не vanilla.

Rgrds, Алексей

Re: [d-kernel] Daedalus kernel

[Anton Farygin]

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

Ed V. Bartosh пишет:
> 
>  AF> Вот такое разбиение, например, для начала:
> 
>  AF> kernel-patches-new-drivers - содержит новые драйвера
>  AF> kernel-patches-bugfixes-drivers - содержит исправления для
>  AF> существующих драйверов
> 
>  AF> kernel-patches-security - включает в себя secrurity-fixes
>  AF> kernel-patches-update-drivers - содержит в себе обновления для
>  AF> драйверов до новых версий.
> 
>  AF> далее по такому-же принципу ;-)
> 
>  AF> Т.е. - бить или нет по категориям я бы не стал. По моему с железом все
>  AF> достаточно прозрачно и если патч не вносит изменения никуда, кроме
>  AF> кода самого драйвера - то его вполне можно включать всегда.
> Зачем так зажимать схему ? Это вариант, противоположный вынесению
> каждого патча в отдельный пакет. Я считаю, что нужен компромисс, то
> есть в данном случае все-таки группировка по категориям.
> Если мне, например, не нужны патчи, касающиеся видео, или, скажем
> ide, то я и не буду их прикладывать. Тем более, что частенько они
> правят не только свой код.
> Мне кажется, что некая гибкость в этом деле не помешает.
> 
> Предлагаю для железных патчей категории по принципу схемы 
> каталогов в сорцах:
> kernel-patches-drivers-net
> kernel-patches-drivers-scsi
> kernel-patches-drivers-ide
> kernel-patches-net
> kernel-patches-fs
> 
> И подкатегории fixes, updates, new, как Вы предлагаете.
> 
> Точно так же можно поступить и с остальными, зачем велосипед
> изобретать, если в ядре уже есть устоявшаяся иерархия.

Хм... наверное это правильно - идти по иерархии в ядре, но как быть с 
особо тяжелыми случаями, когда необходимо наложить часть патчей на scsi 
и часть патчей на net ?

Или особо тяжелые случаи - в морг ? ;-)

Rgds,
Rider

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

Re: [d-kernel] Sisyphus kernel

[aen]

Anton Farygin пишет:

> aen пишет:
>
>> Anton Farygin пишет:
>>
>>>
>>> А что такое critical bugfixes ?
>>>
>>> Является ли неработоспособность какой-то железки critical ?
>>
>>
>>
>> Для vanilla -- думаю, что нет.  В конце концов, мы собираем up -- оно 
>> наше основное ядро, а не vanilla.
>
>
> Тогда наверное стоит на vanilla накладывать только патчи, исправляющие 
> известные уязвимости.. не более того.

Да-да, о том и речь.

Rgrds, Алексей

Re: [d-kernel] Daedalus kernel

[Alexander Bokovoy]

On Tue, Apr 08, 2003 at 06:09:47PM +0400, Anton Farygin wrote:
> >И подкатегории fixes, updates, new, как Вы предлагаете.
> >
> >Точно так же можно поступить и с остальными, зачем велосипед
> >изобретать, если в ядре уже есть устоявшаяся иерархия.
> 
> Хм... наверное это правильно - идти по иерархии в ядре, но как быть с 
> особо тяжелыми случаями, когда необходимо наложить часть патчей на scsi 
> и часть патчей на net ?
> 
> Или особо тяжелые случаи - в морг ? ;-)
Да. И рассортировать по отдельным кабинкам.


-- 
/ Alexander Bokovoy
---
Dishonor will not trouble me, once I am dead.
		-- Euripides

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

Hello, Peter

 PN> Да, это начало. freeswan/acpi в туду, фиксы к железу будут
 PN> по-тихонечку браться из rh и и lkml. 
Отлично. Я постараюсь поучаствовать в этом процессе, если Вы не против.

 >> Еще вопрос по поводу концепции: Каков принцип разрешения конфликтов
 >> между патчами ?
 >> Дело в том, что хотелось бы получить возможность собирать на основании
 >> альтовской базы и другие ядра, но не прикладывая некоторые группы
 >> патчей есть угроза получить реджекты. Предусматриваются ли меры для
 >> придания схеме гибкости еще и в этом направлении ?

 PN> скрипту apply передаётся переменная APPLIED_PATCHES по которой он уже
 PN> может анализировать что и как прикладывать. В дальнейшем планируется
 PN> развитие инфраструктуры apply скриптов.
Понятно. Посмотрим. Если будут какие мысли - я сюда буду писать,
хорошо ?

 PN> Про категоризацию патчей. Господа, я читаю вашу дискуссию, она мне
 PN> очень интересна и я бы был рад, если бы вы продолжали в том же духе :)
 PN> у меня пока формируется мнение, которое и будет высказано в
 PN> последствии.
Угу, не вопрос, подискутируем :)

 PN> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
 PN> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
Я уже в процессе :) Скоро сделаю. Кроме того у нас есть и свои патчи и
апдейты драйверов, которые не помешало бы интегрировать в альтовское
ядро. Я как раз сейчас и готов занимаюсь переделкой ядра под эту
технологию. Предлагаю объединить усилия.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Peter Novodvorsky]

Ed, привет.

ed@sam-solutions.net (Ed V. Bartosh) writes:

> Там в общем-то много чего нет, это же только начало.
> FreeSWAN и типа этого - это макроуровень так сказать. 
> На уровне пониже фиксов к железу нет пока, acpi нет (или не
> планируется ?) 
> и т.д.

Да, это начало. freeswan/acpi в туду, фиксы к железу будут
по-тихонечку браться из rh и и lkml. 

> Еще вопрос по поводу концепции: Каков принцип разрешения конфликтов
> между патчами ?
> Дело в том, что хотелось бы получить возможность собирать на основании
> альтовской базы и другие ядра, но не прикладывая некоторые группы
> патчей есть угроза получить реджекты. Предусматриваются ли меры для
> придания схеме гибкости еще и в этом направлении ?

скрипту apply передаётся переменная APPLIED_PATCHES по которой он уже
может анализировать что и как прикладывать. В дальнейшем планируется
развитие инфраструктуры apply скриптов.


Про категоризацию патчей. Господа, я читаю вашу дискуссию, она мне
очень интересна и я бы был рад, если бы вы продолжали в том же духе :)
у меня пока формируется мнение, которое и будет высказано в
последствии.

Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.

Спасибо за дискуссию.
Nidd

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] Daedalus kernel

[Alexander Bokovoy]

On Tue, Apr 08, 2003 at 07:50:02PM +0400, Peter Novodvorsky wrote:
> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
Я думаю, что этим будет заниматься и так уже занимающийся этим Алексей
Котович.

Петя, ты не против простого выбрасывания имеющегося 1.9.2 из Сизифа с
заменой его на 1.2.1?
-- 
/ Alexander Bokovoy
---
You fill a much-needed gap.

Re: [d-kernel] Daedalus kernel

[Peter Novodvorsky]

Alexander Bokovoy <a.bokovoy@sam-solutions.net> writes:

> On Tue, Apr 08, 2003 at 07:50:02PM +0400, Peter Novodvorsky wrote:
>> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
>> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
> Я думаю, что этим будет заниматься и так уже занимающийся этим Алексей
> Котович.
>
> Петя, ты не против простого выбрасывания имеющегося 1.9.2 из Сизифа с
> заменой его на 1.2.1?

Я за. Если не против тот, кто уже попытался воспользоваться EVMS 1.9.2
(hopefully noone).

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] Daedalus kernel

[Alexander Bokovoy]

On Tue, Apr 08, 2003 at 08:00:24PM +0400, Peter Novodvorsky wrote:
> Alexander Bokovoy <a.bokovoy@sam-solutions.net> writes:
> 
> > On Tue, Apr 08, 2003 at 07:50:02PM +0400, Peter Novodvorsky wrote:
> >> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
> >> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
> > Я думаю, что этим будет заниматься и так уже занимающийся этим Алексей
> > Котович.
> >
> > Петя, ты не против простого выбрасывания имеющегося 1.9.2 из Сизифа с
> > заменой его на 1.2.1?
> 
> Я за. Если не против тот, кто уже попытался воспользоваться EVMS 1.9.2
> (hopefully noone).
Как им кто-то сумеет воспользоваться, если user space в Сизифе пока еще 1.2? :)
-- 
/ Alexander Bokovoy
---
<erikm> cleartape: kernels don't do magic, they just implement mechanisms

	- Erik Mouw on #kernelnewbies

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

Hello, Peter

 >> Отлично. Я постараюсь поучаствовать в этом процессе, если Вы не
 >> против.

 PN> Я только за. Всеми руками :)
Ну и чудненько. Мне все, что я натворю через Сашу передавать 
или прям сюда кидать :) ? Или может есть более щадящие варианты :) ?

 PN> Раз дискуссия затухла: я считаю "распределение по Бартошу"
 PN> (kernel-patch-ide, kernel-patch-net, etc.) наиболее эффективным и
 PN> жизнеспособным. 
Она затухла из-за времени суток, IMHO. Можно подождать, может народ
завтра еще чего напишет. 

 PN> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
 PN> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
 >> Я уже в процессе :) Скоро сделаю. Кроме того у нас есть и свои патчи и
 >> апдейты драйверов, которые не помешало бы интегрировать в альтовское
 >> ядро. Я как раз сейчас и готов занимаюсь переделкой ядра под эту
 >> технологию. Предлагаю объединить усилия.

 PN> Да. Но насчёт апдейтов к драйверам, надо договориться, как их
 PN> распихивать по пакетам. Моё мнение см. выше.
Не нашел че-то :( 
Я скоро до этого доберусь и подумаю. Напишу.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Peter Novodvorsky]

ed@sam-solutions.net (Ed V. Bartosh) writes:

>  PN> Да, это начало. freeswan/acpi в туду, фиксы к железу будут
>  PN> по-тихонечку браться из rh и и lkml. 
> Отлично. Я постараюсь поучаствовать в этом процессе, если Вы не
> против.

Я только за. Всеми руками :)

>  PN> скрипту apply передаётся переменная APPLIED_PATCHES по которой он уже
>  PN> может анализировать что и как прикладывать. В дальнейшем планируется
>  PN> развитие инфраструктуры apply скриптов.
> Понятно. Посмотрим. Если будут какие мысли - я сюда буду писать,
> хорошо ?

Конечно :) Это тоже приветствуется.

>  PN> Про категоризацию патчей. Господа, я читаю вашу дискуссию, она мне
>  PN> очень интересна и я бы был рад, если бы вы продолжали в том же духе :)
>  PN> у меня пока формируется мнение, которое и будет высказано в
>  PN> последствии.
> Угу, не вопрос, подискутируем :)

Раз дискуссия затухла: я считаю "распределение по Бартошу"
(kernel-patch-ide, kernel-patch-net, etc.) наиболее эффективным и
жизнеспособным. 

>  PN> Про EVMS. Если есть желание поддерживать EVMS 1.2, я буду рад, если бы
>  PN> кто-нибудь из sam занялся поддержкой пакета kernel-patch-evms.
> Я уже в процессе :) Скоро сделаю. Кроме того у нас есть и свои патчи и
> апдейты драйверов, которые не помешало бы интегрировать в альтовское
> ядро. Я как раз сейчас и готов занимаюсь переделкой ядра под эту
> технологию. Предлагаю объединить усилия.

Да. Но насчёт апдейтов к драйверам, надо договориться, как их
распихивать по пакетам. Моё мнение см. выше.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] Daedalus kernel

[Anton Farygin]

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

Peter Novodvorsky пишет:
> Раз дискуссия затухла: я считаю "распределение по Бартошу"
> (kernel-patch-ide, kernel-patch-net, etc.) наиболее эффективным и
> жизнеспособным. 
Да, я тоже вроде как согласился с такой схемой... да нам и не мешает 
никто через годик изменить ее, набрав некоторый положительный (или 
отрицательный) опыт поддержки пакетов.

Вообще мне хотелось бы иметь возможность собирать следующие ядра:

vanilla + fixes + new drivers (все)
vanilla + fixes + new drivers + новые возможности (например OpenAFS или 
grsecurity или rsbac или openwall)

Т.е. - фактически у меня есть желание иметь некоторое почти ванильное 
ядро с исправлениями для оборудования, на которое мы уже станем 
накладывать патчи для получения новой функциональности.

Rgds,
Rider

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

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

Hello, Anton

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

Я предлагал это:
kernel-patches-drivers-net
kernel-patches-drivers-scsi
kernel-patches-drivers-ide
kernel-patches-net
kernel-patches-fs

И еще подкатегории 
fixes, updates, new
Но так получается слишком длинно и непонятно для скажем новых
драйверов:
kernel-patches-drivers-scsi-new...

Может быть так :

Для патчей:
kernel-patches-[drivers-{scsi|net|ide|...}]|[fs-{xfs|ext2|...}]|[net-{sunrpc|ethernet|...}]

Для апдейтов ?
kernel-updates- ....

Для новых драйверов ?
kernel-drivers- ....
Здесь можно не валить все в один пакет, а разделить
по принципу один драйвер - один пакет.

Для секурити фиксов ?
kernel-secfixes

Для секурити фич ?
kernel-security-

Для остального ?

При таком раскладе evms попадает в kernel-drivers-evms
xfs - в  kernel-fs-xfs
rsbac - в kernel-security-rsbac
фиксы для scsi драйверов - в kernel-patches-drivers-scsi
новые драйверы для, скажем aic79xx - в kernel-drivers-scsi-aic79xx
апдейты к существующим драйверам - в kernel-updates-drivers-scsi-aic79xx

Так ? Не слишком длинно ?

 AF> Вообще мне хотелось бы иметь возможность собирать следующие ядра:

 AF> vanilla + fixes + new drivers (все)
 AF> vanilla + fixes + new drivers + новые возможности (например
 AF> OpenAFS или grsecurity или rsbac или openwall)

 AF> Т.е. - фактически у меня есть желание иметь некоторое почти
 AF> ванильное ядро с исправлениями для оборудования, на которое
 AF> мы уже станем накладывать патчи для получения новой
 AF> функциональности.
А мне бы хотелось, чтобы я мог на основании Сизифа собирать
ядра с разной функциональностью с наименьшим гимором. И чем дальше
будет исходный материал от ванилы, тем лучше.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[Ed V. Bartosh]

Hello, Peter

 PN> Раз дискуссия затухла: я считаю "распределение по Бартошу"
 PN> (kernel-patch-ide, kernel-patch-net, etc.) наиболее эффективным и
 PN> жизнеспособным.

 a> <skip>

 >> 
 PN> Да. Но насчёт апдейтов к драйверам, надо договориться,
 >> как их

 PN> распихивать по пакетам. Моё мнение см. выше.
 >> Не нашел че-то :(

 a> См. выше :-)
:) А я думал, что выше по треду. Нет, это за ответ не катит,
отвечай на мое письмо с примерами.

Вот тебе пара патчиков, пока не забыл :

--- /home/rpm/kernel-patch-secfixes/SOURCES/secfixes-apply      2003-03-18 16:36:40 +0300
+++ ./secfixes  2003-04-08 19:56:49 +0400
@@ -3,7 +3,7 @@
 PATCH_NAME=secfixes
 
 if [ $KVER == 2.4.21pre5 ]; then
-    PATCH_FILES=/usr/src/patches/$PATCH_NAME/$PATCH_NAME-2.4.21pre5.patch
+    PATCH_FILES=/usr/src/patches/$PATCH_NAME/*
 fi
 
 echo "Applying patches $PATCH_NAME"

--- /home/rpm/kernel-patch-evms/SOURCES/evms-apply      2003-03-31 16:41:08 +0400
+++ ./evms      2003-04-08 19:58:46 +0400
@@ -17,7 +17,10 @@
     exit 0;
 fi
 
-cat $PATCH_FILES | patch -p1
+for f in $PATCH_FILES ; do
+       echo -e "\nApplying patch $f ...\n"
+       cat $f | patch -p1
+done
 
 touch patches/APPLIED_$PATCH_NAME
 
Первый можно считать багфиксом, а второй - feature request-ом :)
Можно, кстати, подумать и на тему 
'touch patches/APPLIED_$PATCH_NAME/$f' в цикле.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Daedalus kernel

[aen]

Ed V. Bartosh пишет:

>
> PN> Раз дискуссия затухла: я считаю "распределение по Бартошу"
> PN> (kernel-patch-ide, kernel-patch-net, etc.) наиболее эффективным и
> PN> жизнеспособным. 
>  
>
<skip>

>
> 
> PN> Да. Но насчёт апдейтов к драйверам, надо договориться, как их
> PN> распихивать по пакетам. Моё мнение см. выше.
>Не нашел че-то :( 
>
См. выше :-)

Rgrds, Алексей