[d-kernel] IDE modularization again

[d-kernel] IDE modularization again

[Ed V. Bartosh]

День добрый.

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

В результате очередных "прений" на канале было решено следующее:
1. IDE модуляризации как таковой - быть
2. Делать ее будем сразу в Сизифе на примере отдельного тестового 
   ядра ветки 2.6, после обкатки интегрировать в std.
3. Основные userspace пакеты, подлежащий изменениям - mkinitrd и
   ldetect. Кроме этого, могут быть затронуты installer, kudzu (или его аналог)

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

Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect - есть ли
возможность оперативно включить патчи для поддержки модуляризации IDE
в эти пакеты ?


Еще раз прошу всех заинтересованных лиц включаться в обсуждение.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
> День добрый.
> 
> Вопрос этот муссируется уже давно, хотелось бы все-таки направить его
> в практическое русло.
> 
> В результате очередных "прений" на канале было решено следующее:
> 1. IDE модуляризации как таковой - быть
> 2. Делать ее будем сразу в Сизифе на примере отдельного тестового 
>    ядра ветки 2.6, после обкатки интегрировать в std.
> 3. Основные userspace пакеты, подлежащий изменениям - mkinitrd и
>    ldetect. Кроме этого, могут быть затронуты installer, kudzu (или его аналог)
> 
> Предлагаю обсудить вопросы, связанные с модуляризацией и здесь.
> 
> Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect - есть ли
> возможность оперативно включить патчи для поддержки модуляризации IDE
> в эти пакеты ?

ldetect-lst как класс должен исчезнуть... соответственно ничего включать в
этот пакет не нужно. Добавить поддержку в его аналог IMHO необходимо.

Кстати, господа, можно ли для новых modutils сделать динамическую
библиотеку ?

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

>> Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect - есть ли
>> возможность оперативно включить патчи для поддержки модуляризации IDE
>> в эти пакеты ?
>
> ldetect-lst как класс должен исчезнуть... соответственно ничего включать в
> этот пакет не нужно. Добавить поддержку в его аналог IMHO необходимо.
А какой у него будет аналог ? Хочу высказать пожелание вынести базу
pci id (pcilist) в отдельный пакет. Это планируется сделать ?

> Кстати, господа, можно ли для новых modutils сделать динамическую
> библиотеку ?
Это имеет какое-то отношение к топику ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 02:22:24PM +0200, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> >> Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect - есть ли
> >> возможность оперативно включить патчи для поддержки модуляризации IDE
> >> в эти пакеты ?
> >
> > ldetect-lst как класс должен исчезнуть... соответственно ничего включать в
> > этот пакет не нужно. Добавить поддержку в его аналог IMHO необходимо.
> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
> pci id (pcilist) в отдельный пакет. Это планируется сделать ?

Она и сейчас в отдельном пакете (ldetect-lst).

Или ты про то, что бы разнести базу по типам устройств?

> 
> > Кстати, господа, можно ли для новых modutils сделать динамическую
> > библиотеку ?
> Это имеет какое-то отношение к топику ?

Небольшое - я не хочу использовать system() на утилиты из modutils ;-)

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Zhenja Kaluta]

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

 AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
 >>  Вопрос этот муссируется уже давно, хотелось бы все-таки направить
 >>  его в практическое русло.
 >>  
 >>  В результате очередных "прений" на канале было решено следующее:
 >>  1. IDE модуляризации как таковой - быть 2. Делать ее будем сразу
 >>  в Сизифе на примере отдельного тестового
 >>     ядра ветки 2.6, после обкатки интегрировать в std.
 >>  3. Основные userspace пакеты, подлежащий изменениям - mkinitrd и
 >>     ldetect. Кроме этого, могут быть затронуты installer, kudzu
 >>     (или его аналог)
 >>  
 >>  Предлагаю обсудить вопросы, связанные с модуляризацией и здесь.
 >>  
 >>  Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect -
 >>  есть ли возможность оперативно включить патчи для поддержки
 >>  модуляризации IDE в эти пакеты ?
  
 AF>  ldetect-lst как класс должен исчезнуть... соответственно ничего
 AF>  включать в этот пакет не нужно. Добавить поддержку в его аналог
 AF>  IMHO необходимо.

фиг с ним, с ldetect, имеется ввиду добавление pci ids от
ide. По каким критериям будем выбирать ide'шные модуля? Выборка по
загруженным на момент запуска mkinitrd модулям у ldv есть, и он обещал
её включить, но этот вопрос обсуждабельный очень даже.
  

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

>> > ldetect-lst как класс должен исчезнуть... соответственно ничего включать в
>> > этот пакет не нужно. Добавить поддержку в его аналог IMHO необходимо.
>> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
>> pci id (pcilist) в отдельный пакет. Это планируется сделать ?
>
> Она и сейчас в отдельном пакете (ldetect-lst).
Это я знаю. Но ты же говоришь, что он должен исчезнуть ?

>
> Или ты про то, что бы разнести базу по типам устройств?
Нет.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
> 
> >>>>> "AF" == Anton Farygin writes:
> 
>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
>  >>  Вопрос этот муссируется уже давно, хотелось бы все-таки направить
>  >>  его в практическое русло.
>  >>  
>  >>  В результате очередных "прений" на канале было решено следующее:
>  >>  1. IDE модуляризации как таковой - быть 2. Делать ее будем сразу
>  >>  в Сизифе на примере отдельного тестового
>  >>     ядра ветки 2.6, после обкатки интегрировать в std.
>  >>  3. Основные userspace пакеты, подлежащий изменениям - mkinitrd и
>  >>     ldetect. Кроме этого, могут быть затронуты installer, kudzu
>  >>     (или его аналог)
>  >>  
>  >>  Предлагаю обсудить вопросы, связанные с модуляризацией и здесь.
>  >>  
>  >>  Один из основных вопросов к мэйнтэйнерам mkinitrd и ldetect -
>  >>  есть ли возможность оперативно включить патчи для поддержки
>  >>  модуляризации IDE в эти пакеты ?
>   
>  AF>  ldetect-lst как класс должен исчезнуть... соответственно ничего
>  AF>  включать в этот пакет не нужно. Добавить поддержку в его аналог
>  AF>  IMHO необходимо.
> 
> фиг с ним, с ldetect, имеется ввиду добавление pci ids от
> ide. По каким критериям будем выбирать ide'шные модуля? Выборка по
> загруженным на момент запуска mkinitrd модулям у ldv есть, и он обещал
> её включить, но этот вопрос обсуждабельный очень даже.

Может быть по PCI классу устройств ?

001     Mass storage controller
001     00      SCSI storage controller
001     01      IDE interface storage controller
001     02      Floppy disk controller
001     03      IPI bus controller
001     04      RAID bus controller
001     80      Unknown mass storage controller


Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 02:32:40PM +0200, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> >> > ldetect-lst как класс должен исчезнуть... соответственно ничего включать в
> >> > этот пакет не нужно. Добавить поддержку в его аналог IMHO необходимо.
> >> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
> >> pci id (pcilist) в отдельный пакет. Это планируется сделать ?
> >
> > Она и сейчас в отдельном пакете (ldetect-lst).
> Это я знаю. Но ты же говоришь, что он должен исчезнуть ?

Так он и будет в отдельном пакете.. просто формат немного поменяется.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Michael Shigorin]

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

On Mon, Feb 16, 2004 at 03:06:45PM +0300, Anton Farygin wrote:
> ldetect-lst как класс должен исчезнуть...

А смысл?  Или его все бросают?  Или нам потребуется иной формат
данных?

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

PS: добавлю по результатам "дискуссии на канале": упоминалось,
что одни из основных грабель -- при переезде с чипсета на чипсет
уже установленной инсталяции.  Варианты и мнения:

- PATA<->PATA: tren говорит, что [в средне-плохом случае]
  свалится на PIO при стандартных портах, т.е. работать будет
  (хоть и медленно);
- PATA<->SATA: при native SATA все сломается, но ab прав в том,
  что это переезд сродни ATA<->SCSI и невиноватая я;
- /me подумал, что если устраивать автодетект и фиксенье
  конфигурации модулей ide при таких переездах -- то в initrd,
  относящемся к цели загрузки failsafe (который может быть более
  "пухлым"), ну или в rc.sysinit при этой цели.

Как вариант -- объявить проблему организационной и посвятить ей
страничку "Обновление/замена аппаратного обеспечения" в
документации.

-- 
 ---- 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] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 02:42:37PM +0200, Michael Shigorin wrote:
> On Mon, Feb 16, 2004 at 03:06:45PM +0300, Anton Farygin wrote:
> > ldetect-lst как класс должен исчезнуть...
> 
> А смысл?  Или его все бросают?  Или нам потребуется иной формат
> данных?
> 
> (я действительно не предполагаю ответов, но если кардинальных
> изменений не требуется -- то смысла форкаться лишний раз на том,
> что является общей головной болью всех дистрибуторов -- не вижу)

Форкаться от кого ? У всех этот формат свой. 

К тому же новый формат совместим со старым - просто в него добавляются
расширения для поддержки нескольких разных модулей для одного устройства и
команд настройки.

> 
> PS: добавлю по результатам "дискуссии на канале": упоминалось,
> что одни из основных грабель -- при переезде с чипсета на чипсет
> уже установленной инсталяции.  Варианты и мнения:
> 
> - PATA<->PATA: tren говорит, что [в средне-плохом случае]
>   свалится на PIO при стандартных портах, т.е. работать будет
>   (хоть и медленно);
> - PATA<->SATA: при native SATA все сломается, но ab прав в том,
>   что это переезд сродни ATA<->SCSI и невиноватая я;

а SATA<->SATA ?

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 03:46:49PM +0300, Anton Farygin wrote:
> On Mon, Feb 16, 2004 at 02:42:37PM +0200, Michael Shigorin wrote:
> > On Mon, Feb 16, 2004 at 03:06:45PM +0300, Anton Farygin wrote:
> > > ldetect-lst как класс должен исчезнуть...
> > 
> > А смысл?  Или его все бросают?  Или нам потребуется иной формат
> > данных?
> > 
> > (я действительно не предполагаю ответов, но если кардинальных
> > изменений не требуется -- то смысла форкаться лишний раз на том,
> > что является общей головной болью всех дистрибуторов -- не вижу)
> 
> Форкаться от кого ? У всех этот формат свой. 
> 
> К тому же новый формат совместим со старым - просто в него добавляются
> расширения для поддержки нескольких разных модулей для одного устройства и
> команд настройки.


Т.е. - того что у нас раньше было хаками прибито в kudzu.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Alexey I. Froloff]

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

* Anton Farygin <rider@altlinux.com> [040216 15:47]:
> Т.е. - того что у нас раньше было хаками прибито в kudzu.
Кстати, а kudzu не собирается исчезнуть как класс?

-- 
Regards, Sir Raorn.
-------------------
> Выпускать ALM2.1 с такими изменениями -- слишком сильно,
Тогда назовем его ALM2.2? :)
		-- ldv in devel@

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

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

>> >> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
>> >> pci id (pcilist) в отдельный пакет. Это планируется сделать ?
>> >
>> > Она и сейчас в отдельном пакете (ldetect-lst).
>> Это я знаю. Но ты же говоришь, что он должен исчезнуть ?
>
> Так он и будет в отдельном пакете.. просто формат немного поменяется.
>
Когда на это можно будет взглянуть ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Michael Shigorin]

On Mon, Feb 16, 2004 at 03:46:49PM +0300, Anton Farygin wrote:
> Форкаться от кого ? У всех этот формат свой. 
> [...]Т.е. - того что у нас раньше было хаками прибито в kudzu.

> > - PATA<->PATA: tren говорит, что [в средне-плохом случае]
> > - PATA<->SATA: при native SATA все сломается, но ab прав в том,
> а SATA<->SATA ?

Не отследил.  На самом деле даже для PATA<->SATA случай с
переводом SATA в legacy mode на время переезда (или
передергивания legacy<->native вообще?) заслуживает отдельного
рассмотрения. 

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

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 03:49:50PM +0300, Alexey I. Froloff wrote:
> * Anton Farygin <rider@altlinux.com> [040216 15:47]:
> > Т.е. - того что у нас раньше было хаками прибито в kudzu.
> Кстати, а kudzu не собирается исчезнуть как класс?

Собирается. О том и речь.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 02:50:58PM +0200, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> >> >> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
> >> >> pci id (pcilist) в отдельный пакет. Это планируется сделать ?
> >> >
> >> > Она и сейчас в отдельном пакете (ldetect-lst).
> >> Это я знаю. Но ты же говоришь, что он должен исчезнуть ?
> >
> > Так он и будет в отдельном пакете.. просто формат немного поменяется.
> >
> Когда на это можно будет взглянуть ?

Как только будет что-то работоспособное. Но оно будет только как ядро 2.6
упадет в Sisyphus.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Alexander Bokovoy]

On Mon, Feb 16, 2004 at 03:55:45PM +0300, Anton Farygin wrote:
> On Mon, Feb 16, 2004 at 02:50:58PM +0200, Ed V. Bartosh wrote:
> > Anton Farygin <rider@altlinux.com> writes:
> > 
> > >> >> А какой у него будет аналог ? Хочу высказать пожелание вынести базу
> > >> >> pci id (pcilist) в отдельный пакет. Это планируется сделать ?
> > >> >
> > >> > Она и сейчас в отдельном пакете (ldetect-lst).
> > >> Это я знаю. Но ты же говоришь, что он должен исчезнуть ?
> > >
> > > Так он и будет в отдельном пакете.. просто формат немного поменяется.
> > >
> > Когда на это можно будет взглянуть ?
> 
> Как только будет что-то работоспособное. Но оно будет только как ядро 2.6
> упадет в Sisyphus.
Давай не будем повторять многочисленные ошибки других. Положи в CVS и
открой его внутри Team.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

>> > Так он и будет в отдельном пакете.. просто формат немного поменяется.
>> >
>> Когда на это можно будет взглянуть ?
>
> Как только будет что-то работоспособное. Но оно будет только как ядро 2.6
> упадет в Sisyphus.
>

Понятно. Итого на вопрос "что делать с IDE модуляризацией" на сейчас
мы отвечаем так:

1. Ждать появления в Сизифе ядра 2.6
2. Ждать появления в Сизифе devscan (замены ldetect)
3. Делать отдельный kernel-image с IDE в модулях
4. Слать патчи для поддержки модуляризации в сторону мэйнтейнеров
 devscan и mkinitrd.
5. Доводить схему до уверенно работающей.
6. Переносить на std и остальные ядра.

Пункты 3 и 4 можно делать параллельно, насколько я понимаю.

Так ? Или есть другие варианты развития событий ?

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

Кто что скажет ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Zhenja Kaluta]

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

 AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
 >> 
 >> >>>>> "AF" == Anton Farygin writes:
 >> 
 >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
[...]
 
 >> фиг с ним, с ldetect, имеется ввиду добавление pci ids от ide. По
 >> каким критериям будем выбирать ide'шные модуля? Выборка по
 >> загруженным на момент запуска mkinitrd модулям у ldv есть, и он
 >> обещал её включить, но этот вопрос обсуждабельный очень даже.

 AF> Может быть по PCI классу устройств ?

 AF> 001     Mass storage controller
 AF> 001     00      SCSI storage controller
 AF> 001     01      IDE interface storage controller
 AF> 001     02      Floppy disk controller
 AF> 001     03      IPI bus controller
 AF> 001     04      RAID bus controller
 AF> 001     80      Unknown mass storage controller

Простите, класс у нас уже есть :) ide'шные контроллеры я имел
ввиду. По pcilist'у? Ну, вполне метод. 

К слову, scsi сейчас парсингом modules.conf ищется. 


-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
> 
> >>>>> "AF" == Anton Farygin writes:
> 
>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
>  >> 
>  >> >>>>> "AF" == Anton Farygin writes:
>  >> 
>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
> [...]
>  
>  >> фиг с ним, с ldetect, имеется ввиду добавление pci ids от ide. По
>  >> каким критериям будем выбирать ide'шные модуля? Выборка по
>  >> загруженным на момент запуска mkinitrd модулям у ldv есть, и он
>  >> обещал её включить, но этот вопрос обсуждабельный очень даже.
> 
>  AF> Может быть по PCI классу устройств ?
> 
>  AF> 001     Mass storage controller
>  AF> 001     00      SCSI storage controller
>  AF> 001     01      IDE interface storage controller
>  AF> 001     02      Floppy disk controller
>  AF> 001     03      IPI bus controller
>  AF> 001     04      RAID bus controller
>  AF> 001     80      Unknown mass storage controller
> 
> Простите, класс у нас уже есть :) ide'шные контроллеры я имел
> ввиду. По pcilist'у? Ну, вполне метод. 

Да, по pcilist'у + по найденным устройствам.. т.е. - IMHO mkinitrd должен
вызывать что-то вроде devscan --class 001 --modules, а devscan
соотвественно - возвращать список необходимых для найденных устройств
модулей. Хотя тут все равно остается ряд вопросов:

1) Как быть в случае, если для данного контроллера есть более одного
драйвера
2) Как быть с нежеланием пользователя грузить в initrd соответствующие
драйвера.


> 
> К слову, scsi сейчас парсингом modules.conf ищется. 

IMHO неправильно, хотя - кто знает.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Zhenja Kaluta]

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

 AF>  On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
 >> >>>>> "AF" == Anton Farygin writes:
 >>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
 >>  >> >>>>> "AF" == Anton Farygin writes:
 >>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
 >> [...]
 >>  >> фиг с ним, с ldetect, имеется ввиду добавление pci ids от ide. По
 >>  >> каким критериям будем выбирать ide'шные модуля? Выборка по
 >>  >> загруженным на момент запуска mkinitrd модулям у ldv есть, и он
 >>  >> обещал её включить, но этот вопрос обсуждабельный очень даже.
 >> 
 >>  AF> Может быть по PCI классу устройств ?
 >> 
[...]
 >> Простите, класс у нас уже есть :) ide'шные контроллеры я имел
 >> ввиду. По pcilist'у? Ну, вполне метод. 

 AF> Да, по pcilist'у + по найденным устройствам.. т.е. - IMHO mkinitrd должен
 AF> вызывать что-то вроде devscan --class 001 --modules, а devscan

тогда хватит devscan imho, но это же сделает. А что за зверь, где живет?

 AF> соотвественно - возвращать список необходимых для найденных устройств
 AF> модулей. Хотя тут все равно остается ряд вопросов:

 AF> 1) Как быть в случае, если для данного контроллера есть более одного
 AF> драйвера

грузить тот драйвер, который мы считаем нужным. 

 AF> 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
 AF> драйвера.

проблема modprobe? Мы опять с новыми версиями глянем, но afair у Ulfr
есть идеи по этому поводу.

 >> 
 >> К слову, scsi сейчас парсингом modules.conf ищется. 

 AF> IMHO неправильно, хотя - кто знает.

надо же, мы даже в чём-то согласны ;)

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 03:58:01PM +0200, Zhenja Kaluta wrote:
> 
> >>>>> "AF" == Anton Farygin writes:
> 
>  AF>  On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
>  >> >>>>> "AF" == Anton Farygin writes:
>  >>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
>  >>  >> >>>>> "AF" == Anton Farygin writes:
>  >>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
>  >> [...]
>  >>  >> фиг с ним, с ldetect, имеется ввиду добавление pci ids от ide. По
>  >>  >> каким критериям будем выбирать ide'шные модуля? Выборка по
>  >>  >> загруженным на момент запуска mkinitrd модулям у ldv есть, и он
>  >>  >> обещал её включить, но этот вопрос обсуждабельный очень даже.
>  >> 
>  >>  AF> Может быть по PCI классу устройств ?
>  >> 
> [...]
>  >> Простите, класс у нас уже есть :) ide'шные контроллеры я имел
>  >> ввиду. По pcilist'у? Ну, вполне метод. 
> 
>  AF> Да, по pcilist'у + по найденным устройствам.. т.е. - IMHO mkinitrd должен
>  AF> вызывать что-то вроде devscan --class 001 --modules, а devscan
> 
> тогда хватит devscan imho, но это же сделает. А что за зверь, где живет?

Во внутреннем CVS, пока туда не будет добавлена основаная функциональность
kudzu.

> 
>  AF> соотвественно - возвращать список необходимых для найденных устройств
>  AF> модулей. Хотя тут все равно остается ряд вопросов:
> 
>  AF> 1) Как быть в случае, если для данного контроллера есть более одного
>  AF> драйвера
> 
> грузить тот драйвер, который мы считаем нужным. 

А какой мы считаем нужным ? Может быть пользователь с нами не согласен ?
> 
>  AF> 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
>  AF> драйвера.
> 
> проблема modprobe? Мы опять с новыми версиями глянем, но afair у Ulfr
> есть идеи по этому поводу.

Нет, проблема в том, что devscan нам выдаст кучу устройств, а
пользователую нужно например только SCSI грузить.

> 
>  >> 
>  >> К слову, scsi сейчас парсингом modules.conf ищется. 
> 
>  AF> IMHO неправильно, хотя - кто знает.
> 
> надо же, мы даже в чём-то согласны ;)

Ну не всегда же ;-)

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

> Да, по pcilist'у + по найденным устройствам.. т.е. - IMHO mkinitrd должен
> вызывать что-то вроде devscan --class 001 --modules, а devscan
> соотвественно - возвращать список необходимых для найденных устройств
> модулей. Хотя тут все равно остается ряд вопросов:
>
> 1) Как быть в случае, если для данного контроллера есть более одного
> драйвера.
Грузить первый попавшийся и принять меры к тому, чтобы дефолтный находился
первым. Если пользователь захочет другой - попользует --with MODULENAME,
который будет иметь более высокий приоритет.

> 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
> драйвера.
--without MODULENAME ?

>> 
>> К слову, scsi сейчас парсингом modules.conf ищется. 
>
> IMHO неправильно, хотя - кто знает.
Приведи пример, когда это может быть нужно, плз.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 04:09:14PM +0200, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> > Да, по pcilist'у + по найденным устройствам.. т.е. - IMHO mkinitrd должен
> > вызывать что-то вроде devscan --class 001 --modules, а devscan
> > соотвественно - возвращать список необходимых для найденных устройств
> > модулей. Хотя тут все равно остается ряд вопросов:
> >
> > 1) Как быть в случае, если для данного контроллера есть более одного
> > драйвера.
> Грузить первый попавшийся и принять меры к тому, чтобы дефолтный находился
> первым. Если пользователь захочет другой - попользует --with MODULENAME,
> который будет иметь более высокий приоритет.
> 
> > 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
> > драйвера.
> --without MODULENAME ?
> 
> >> 
> >> К слову, scsi сейчас парсингом modules.conf ищется. 
> >
> > IMHO неправильно, хотя - кто знает.
> Приведи пример, когда это может быть нужно, плз.

Нужно парсить ?

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

И соответственно прописал его в modules.conf.

Хотя - тут мы можем логику devscan навернуть и выдавать тот самый драйвер,
который прописан в modules.conf вместо нашего дефолтного.

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Zhenja Kaluta]

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

 AF>  On Mon, Feb 16, 2004 at 03:58:01PM +0200, Zhenja Kaluta wrote:
 >> >>>>> "AF" == Anton Farygin writes:
 >>  AF>  On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
 >>  >> >>>>> "AF" == Anton Farygin writes:
 >>  >>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
 >>  >>  >> >>>>> "AF" == Anton Farygin writes:
 >>  >>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
[...]
 >> 
 >>  AF> соотвественно - возвращать список необходимых для найденных устройств
 >>  AF> модулей. Хотя тут все равно остается ряд вопросов:
 >> 
 >>  AF> 1) Как быть в случае, если для данного контроллера есть более одного
 >>  AF> драйвера
 >> 
 >> грузить тот драйвер, который мы считаем нужным. 

 AF> А какой мы считаем нужным ? Может быть пользователь с нами не согласен ?

в pci list'е на данный момент только один драйвер. При расширении
никто не мешает спросить в интерактивном режиме, либо механизм
alternatives/override для модулей. 

 >> 
 >>  AF> 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
 >>  AF> драйвера.
 >> 
 >> проблема modprobe? Мы опять с новыми версиями глянем, но afair у Ulfr
 >> есть идеи по этому поводу.

 AF> Нет, проблема в том, что devscan нам выдаст кучу устройств, а
 AF> пользователую нужно например только SCSI грузить.

grep'ом, господа, grep'ом. Или у него не будет вывода с указанием
класса?

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Anton Farygin]

On Mon, Feb 16, 2004 at 04:13:42PM +0200, Zhenja Kaluta wrote:
> 
> >>>>> "AF" == Anton Farygin writes:
> 
>  AF>  On Mon, Feb 16, 2004 at 03:58:01PM +0200, Zhenja Kaluta wrote:
>  >> >>>>> "AF" == Anton Farygin writes:
>  >>  AF>  On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
>  >>  >> >>>>> "AF" == Anton Farygin writes:
>  >>  >>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
>  >>  >>  >> >>>>> "AF" == Anton Farygin writes:
>  >>  >>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
> [...]
>  >> 
>  >>  AF> соотвественно - возвращать список необходимых для найденных устройств
>  >>  AF> модулей. Хотя тут все равно остается ряд вопросов:
>  >> 
>  >>  AF> 1) Как быть в случае, если для данного контроллера есть более одного
>  >>  AF> драйвера
>  >> 
>  >> грузить тот драйвер, который мы считаем нужным. 
> 
>  AF> А какой мы считаем нужным ? Может быть пользователь с нами не согласен ?
> 
> в pci list'е на данный момент только один драйвер. При расширении
> никто не мешает спросить в интерактивном режиме, либо механизм
> alternatives/override для модулей. 
> 
>  >> 
>  >>  AF> 2) Как быть с нежеланием пользователя грузить в initrd соответствующие
>  >>  AF> драйвера.
>  >> 
>  >> проблема modprobe? Мы опять с новыми версиями глянем, но afair у Ulfr
>  >> есть идеи по этому поводу.
> 
>  AF> Нет, проблема в том, что devscan нам выдаст кучу устройств, а
>  AF> пользователую нужно например только SCSI грузить.
> 
> grep'ом, господа, grep'ом. Или у него не будет вывода с указанием
> класса?

Как сделаем, так и будет ;-)

Я вот думаю - может быть куда-то конфиг класть ?

Rgds,
Rider

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Anton Farygin <rider@altlinux.com> writes:

>> >> К слову, scsi сейчас парсингом modules.conf ищется. 
>> >
>> > IMHO неправильно, хотя - кто знает.
>> Приведи пример, когда это может быть нужно, плз.
>
> Нужно парсить ?
>
> Пример: пользователь собрал свой собственный драйвер для его любимой
> железки, для которой мы юзаем ядерный.
>
> И соответственно прописал его в modules.conf.

Это его трудности. Пусть делает себе сам initrd. -with MODULENAME и
-without MODULENAME ему в руки.

>
> Хотя - тут мы можем логику devscan навернуть и выдавать тот самый драйвер,
> который прописан в modules.conf вместо нашего дефолтного.
По-моему это надуманые проблемы и modules.conf парсить - это
совершенно лишнее.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Sergey Vlasov]

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

On Mon, Feb 16, 2004 at 04:20:01PM +0200, Ed V. Bartosh wrote:
> Anton Farygin <rider@altlinux.com> writes:
> 
> >> >> К слову, scsi сейчас парсингом modules.conf ищется. 
> >> >
> >> > IMHO неправильно, хотя - кто знает.
> >> Приведи пример, когда это может быть нужно, плз.
> >
> > Нужно парсить ?
> >
> > Пример: пользователь собрал свой собственный драйвер для его любимой
> > железки, для которой мы юзаем ядерный.
> >
> > И соответственно прописал его в modules.conf.
> 
> Это его трудности. Пусть делает себе сам initrd. -with MODULENAME и
> -without MODULENAME ему в руки.
> 
> >
> > Хотя - тут мы можем логику devscan навернуть и выдавать тот самый драйвер,
> > который прописан в modules.conf вместо нашего дефолтного.
> По-моему это надуманые проблемы и modules.conf парсить - это
> совершенно лишнее.

Или в конце концов завести mkinitrd.conf?

Например, если автоматика будет загонять драйверы для всех
SCSI-контроллеров в initrd, кто-то может захотеть, чтобы туда
добавлялось не всё.  (Вот тут на одной машине есть AHA-2940 с
выдернутым BIOS-ом - на нём магнитооптика висит, его родной setup
почему-то не запускался, а тормоза при загрузке достали.)

"Пусть делает сам себе initrd" - конечно, в определённом смысле тоже
решение, но это же неудобно (придётся об этом вспоминать при каждой
смене ядра, или делать какой-то hook в скриптах).

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

Re: [d-kernel] IDE modularization again

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey Vlasov <vsu@altlinux.ru> writes:

 > On Mon, Feb 16, 2004 at 04:20:01PM +0200, Ed V. Bartosh wrote:
 >> Anton Farygin <rider@altlinux.com> writes:
 >> 
 >> >> >> К слову, scsi сейчас парсингом modules.conf ищется. 
 >> >> >
 >> >> > IMHO неправильно, хотя - кто знает.
 >> >> Приведи пример, когда это может быть нужно, плз.
 >> >
 >> > Нужно парсить ?
 >> >
 >> > Пример: пользователь собрал свой собственный драйвер для его любимой
 >> > железки, для которой мы юзаем ядерный.
 >> >
 >> > И соответственно прописал его в modules.conf.
 >> 
 >> Это его трудности. Пусть делает себе сам initrd. -with MODULENAME и
 >> -without MODULENAME ему в руки.
 >> 
 >> >
 >> > Хотя - тут мы можем логику devscan навернуть и выдавать тот самый драйвер,
 >> > который прописан в modules.conf вместо нашего дефолтного.
 >> По-моему это надуманые проблемы и modules.conf парсить - это
 >> совершенно лишнее.

 > Или в конце концов завести mkinitrd.conf?

 > Например, если автоматика будет загонять драйверы для всех
 > SCSI-контроллеров в initrd, кто-то может захотеть, чтобы туда
 > добавлялось не всё.  (Вот тут на одной машине есть AHA-2940 с
 > выдернутым BIOS-ом - на нём магнитооптика висит, его родной setup
 > почему-то не запускался, а тормоза при загрузке достали.)

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

-- 

Re: [d-kernel] IDE modularization again

[Michael Shigorin]

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

On Mon, Feb 16, 2004 at 05:33:15PM +0300, Sergey Vlasov wrote:
> > > Пример: пользователь собрал свой собственный драйвер для
> > > его любимой железки, для которой мы юзаем ядерный.
> > > И соответственно прописал его в modules.conf.
> > Это его трудности. Пусть делает себе сам initrd. -with
> решение, но это же неудобно (придётся об этом вспоминать при
> каждой смене ядра, или делать какой-то hook в скриптах).

Погоди.  Давай перед "счастьем, всем, бесплатно" (в том числе и
самым хитрым, которые с напильником) сделаем "счастье в
поддерживаемом объеме".

У вас с zerg@ повторяющееся рвение учесть все "проблемы негров".
Как "негр" ;-) -- оное рвение могу только приветствовать, но как
человек, которого тоже теребят "нормальные пользователи" --
предложу оставить селективные хитровыпендренные варианты, которые
неминуемо есть следствие __ручного__ вмешательства -- на потом.

Потому что или вмешивался умный человек и он сам в курсе, или
вмешивался чайник и он ССЗБ (и ничем ты его от этого техническим
не полечишь -- говорю как человек, который в том году вывел из
строя "домохозяечную" стиралку поворотом ручки против часовой).

OK?

-- 
 ---- 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] IDE modularization again

[Ed V. Bartosh]

Sergey Vlasov <vsu@altlinux.ru> writes:

>> По-моему это надуманые проблемы и modules.conf парсить - это
>> совершенно лишнее.
>
> Или в конце концов завести mkinitrd.conf?
Идея здравая. Но я поддерживаю ее не в части парсинга modules.conf, а
в части упоминания там модулей для включения/исключения в/из initrd,
чтобы руками каждый раз не указывать.

> Например, если автоматика будет загонять драйверы для всех
> SCSI-контроллеров в initrd, кто-то может захотеть, чтобы туда
> добавлялось не всё.  (Вот тут на одной машине есть AHA-2940 с
> выдернутым BIOS-ом - на нём магнитооптика висит, его родной setup
> почему-то не запускался, а тормоза при загрузке достали.)
По результатам разговоров на канале автоматика будет загонять все
модули только для fail-safe вариантов загрузки, то есть не всегда.
А так да :)

> "Пусть делает сам себе initrd" - конечно, в определённом смысле тоже
> решение, но это же неудобно (придётся об этом вспоминать при каждой
> смене ядра, или делать какой-то hook в скриптах).
Вот я и предлагаю для этого использовать mkinitrd.conf. но попозже, поскольку
это уже шашечки, а нам бы поехать для начала :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Zhenja Kaluta]

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

 AF>  On Mon, Feb 16, 2004 at 03:58:01PM +0200, Zhenja Kaluta wrote:
 >> >>>>> "AF" == Anton Farygin writes:
 >>  AF>  On Mon, Feb 16, 2004 at 03:21:29PM +0200, Zhenja Kaluta wrote:
 >>  >> >>>>> "AF" == Anton Farygin writes:
 >>  >>  AF>  On Mon, Feb 16, 2004 at 02:28:39PM +0200, Zhenja Kaluta wrote:
 >>  >>  >> >>>>> "AF" == Anton Farygin writes:
 >>  >>  >>  AF>   On Mon, Feb 16, 2004 at 01:28:50PM +0200, Ed V. Bartosh wrote:
[...]
 >> тогда хватит devscan imho, но это же сделает. А что за зверь, где живет?

 AF> Во внутреннем CVS, пока туда не будет добавлена основаная функциональность
 AF> kudzu.

А когда, приблизительно, сей чудный утиль будет того?

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] mkinitrd.conf

[Dmitry V. Levin]

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

On Mon, Feb 16, 2004 at 05:12:16PM +0200, Ed V. Bartosh wrote:
> Sergey Vlasov <vsu@altlinux> writes:
> 
> >> По-моему это надуманые проблемы и modules.conf парсить - это
> >> совершенно лишнее.
> >
> > Или в конце концов завести mkinitrd.conf?
> Идея здравая. Но я поддерживаю ее не в части парсинга modules.conf, а
> в части упоминания там модулей для включения/исключения в/из initrd,
> чтобы руками каждый раз не указывать.
> 
> > Например, если автоматика будет загонять драйверы для всех
> > SCSI-контроллеров в initrd, кто-то может захотеть, чтобы туда
> > добавлялось не всё.  (Вот тут на одной машине есть AHA-2940 с
> > выдернутым BIOS-ом - на нём магнитооптика висит, его родной setup
> > почему-то не запускался, а тормоза при загрузке достали.)
> По результатам разговоров на канале автоматика будет загонять все
> модули только для fail-safe вариантов загрузки, то есть не всегда.
> А так да :)
> 
> > "Пусть делает сам себе initrd" - конечно, в определённом смысле тоже
> > решение, но это же неудобно (придётся об этом вспоминать при каждой
> > смене ядра, или делать какой-то hook в скриптах).
> Вот я и предлагаю для этого использовать mkinitrd.conf. но попозже, поскольку
> это уже шашечки, а нам бы поехать для начала :)

Меня убедили в необходимости mkinitrd.conf для регулирования поведения
mkinitrd.  Давайте определимся, как оно должно быть устроено.


-- 
ldv

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

Re: [d-kernel] mkinitrd.conf

[Zhenja Kaluta]

>>>>> "DVL" == Dmitry V. Levin writes:

 DVL>   On Mon, Feb 16, 2004 at 05:12:16PM +0200, Ed V. Bartosh wrote:
 >> Вот я и предлагаю для этого использовать mkinitrd.conf. но
 >> попозже, поскольку это уже шашечки, а нам бы поехать для
 >> начала :)
  
 DVL>  Меня убедили в необходимости mkinitrd.conf для регулирования
 DVL>  поведения mkinitrd.  Давайте определимся, как оно должно быть
 DVL>  устроено.
  
набор необходимых нам переменных, подключаемый через "." .

Например, из того, что нам нужно -- тип initrd (полный для failsafe,
необходимый для поднятия), дополнительные модули, исключаемые
устройства, необходимо ли давать возможность busybox shell'а, ну и в
таком духе.

А зачем так в эту тему углубились? Это, вообще, мелочь, есть ведь
более общие проблемы, например, как бы познакомиться с великим
детектором устройств (для начала) и подстроить под него поиск
драйверов? В чуть дальшей перспективе, поднятие рута с lvm'ов.

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] mkinitrd.conf

[Dmitry V. Levin]

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

On Tue, Feb 17, 2004 at 02:22:00PM +0200, Zhenja Kaluta wrote:
> >>>>> "DVL" == Dmitry V. Levin writes:
>  DVL>   On Mon, Feb 16, 2004 at 05:12:16PM +0200, Ed V. Bartosh wrote:
>  >> Вот я и предлагаю для этого использовать mkinitrd.conf. но
>  >> попозже, поскольку это уже шашечки, а нам бы поехать для
>  >> начала :)
>   
>  DVL>  Меня убедили в необходимости mkinitrd.conf для регулирования
>  DVL>  поведения mkinitrd.  Давайте определимся, как оно должно быть
>  DVL>  устроено.
>   
> набор необходимых нам переменных, подключаемый через "." .
> 
> Например, из того, что нам нужно -- тип initrd (полный для failsafe,
> необходимый для поднятия), дополнительные модули, исключаемые
> устройства, необходимо ли давать возможность busybox shell'а, ну и в
> таком духе.

Есть ещё одно предложение - хранить в mkinitrd.conf дополнительные
параметры запуска mkinitrd (которые, конечно, можно будет при желании
проигнорировать при запуске mkinitrd вручную).

> А зачем так в эту тему углубились? Это, вообще, мелочь [...]

Нет, это не мелочь.


-- 
ldv

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

Re: [d-kernel] mkinitrd.conf

[Zhenja Kaluta]

>>>>> "DVL" == Dmitry V. Levin writes:

 DVL>   On Tue, Feb 17, 2004 at 02:22:00PM +0200, Zhenja Kaluta wrote:
 >>  >>>>> "DVL" == Dmitry V. Levin writes:
 >>   DVL>   On Mon, Feb 16, 2004 at 05:12:16PM +0200, Ed V. Bartosh wrote:
 >>   >> Вот я и предлагаю для этого использовать mkinitrd.conf. но
 >>   >> попозже, поскольку это уже шашечки, а нам бы поехать для
 >>   >> начала :)
 >>
 >>   DVL>  Меня убедили в необходимости mkinitrd.conf для
 >>   DVL>  регулирования поведения mkinitrd.  Давайте определимся,
 >>   DVL>  как оно должно быть устроено.
 >>
 >>  набор необходимых нам переменных, подключаемый через "." .
 >>  
 >>  Например, из того, что нам нужно -- тип initrd (полный для
 >>  failsafe, необходимый для поднятия), дополнительные модули,
 >>  исключаемые устройства, необходимо ли давать возможность busybox
 >>  shell'а, ну и в таком духе.
  
 DVL>  Есть ещё одно предложение - хранить в mkinitrd.conf
 DVL>  дополнительные параметры запуска mkinitrd (которые, конечно,
 DVL>  можно будет при желании проигнорировать при запуске mkinitrd
 DVL>  вручную).

так да, а то что было -- не то же самое? :)

Итого, по этому вопросу разногласий нет?

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Sergey]

On Monday 16 February 2004 16:42, Michael Shigorin wrote:

> - PATA<->SATA: при native SATA все сломается, но ab прав в том,
>   что это переезд сродни ATA<->SCSI и невиноватая я;

А где засада, кроме fstab и лоадера ? Что-то я не соображу...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [d-kernel] IDE modularization again

[Michael Shigorin]

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

On Fri, Feb 20, 2004 at 12:37:42AM +0400, Sergey wrote:
> > - PATA<->SATA: при native SATA все сломается, но ab прав в
> > том, что это переезд сродни ATA<->SCSI и невиноватая я;
> А где засада, кроме fstab и лоадера ? Что-то я не соображу...

Модули.

-- 
 ---- 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] IDE modularization again

[Anton Farygin]

On Fri, Feb 20, 2004 at 12:37:42AM +0400, Sergey wrote:
> On Monday 16 February 2004 16:42, Michael Shigorin wrote:
> 
> > - PATA<->SATA: при native SATA все сломается, но ab прав в том,
> >   что это переезд сродни ATA<->SCSI и невиноватая я;
> 
> А где засада, кроме fstab и лоадера ? Что-то я не соображу...

Пересборка initrd с переконфигурацией машины

[d-kernel] 2.4.24

[Zhenja Kaluta]

Hi!

Господа, на сколько я понимаю, у vsu всё готово для 2.4.24. Раз
обвязку переделывть не будем, давайте его в сизиф?
  

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] IDE modularization again

[Sergey]

On Friday 20 February 2004 12:44, Michael Shigorin wrote:

> > > том, что это переезд сродни ATA<->SCSI и невиноватая я;
> > А где засада, кроме fstab и лоадера ? Что-то я не соображу...
> 
> Модули.

А в initrd их заранее засунуть совесть не позволяет ? Конечно,
полностью это не автоматизируешь, но можно и какую-нибудь ручную 
докунфигурялку придумать. В основном, когда железки меняешь,
представляешь, на что. А для ленивых можно попробовать придумать 
мини-cd, с которым можно загрузиться и который новое железо 
переопределит и конфиги поменяет. И остается еще вариант засунуть 
в initrd весь набор дисковых модулей. ;-)
Типа mkinitrd_for_upgreate что-нибудь сделать...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [d-kernel] 2.4.24

[Aleksey Avdeev]

Zhenja Kaluta wrote:
> Hi!
> 
> Господа, на сколько я понимаю, у vsu всё готово для 2.4.24. Раз
> обвязку переделывть не будем, давайте его в сизиф?

   Вопрос (для меня существенный): будет ли там пат для SIS5513?

-- 

С уважением. Алексей.

Re: [d-kernel] 2.4.24

[Ed V. Bartosh]

Hi,

> Господа, на сколько я понимаю, у vsu всё готово для 2.4.24. Раз
> обвязку переделывть не будем, давайте его в сизиф?
>   
Вот-вот. Вроде уже 2004 год на дворе, а у нас все еще 2.4.22.
Нехорошо как-то. 
Хотя, если делать, то уже сразу 2.4.25, но не думаю, что это намного труднее.

В чем, собственно, проблемы ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Ed V. Bartosh]

Hello,

>> > > том, что это переезд сродни ATA<->SCSI и невиноватая я;
>> > А где засада, кроме fstab и лоадера ? Что-то я не соображу...
>> 
>> Модули.
>
> А в initrd их заранее засунуть совесть не позволяет ? 
Позволяет, но толстый он будет, да и не нужно это в 99% случаев.

> Конечно,
> полностью это не автоматизируешь, но можно и какую-нибудь ручную 
> докунфигурялку придумать. В основном, когда железки меняешь,
> представляешь, на что. А для ленивых можно попробовать придумать 
> мини-cd, с которым можно загрузиться и который новое железо 
> переопределит и конфиги поменяет. И остается еще вариант засунуть 
> в initrd весь набор дисковых модулей. ;-)
> Типа mkinitrd_for_upgreate что-нибудь сделать...
Было принято решение совать все, что можно в fail_safe initrd, там же
делать детектирование и подъем нужного.
Этим будет заниматься некая неизвестная тулза под названием devscan,
которую мы все с нетерпением ждем. 

Мы вообще все время чего-то ждем. К чему бы это :) ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] IDE modularization again

[Michael Shigorin]

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

On Fri, Feb 20, 2004 at 11:49:39AM +0200, Ed V. Bartosh wrote:
> Мы вообще все время чего-то ждем. К чему бы это :) ?

К дезорганизации.

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

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