[d-kernel] Вынос IDE в модуль

[d-kernel] Вынос IDE в модуль

[Vitaly Lipatov]

А какие у нас остались аргументы в пользу того,
чтобы (для ядра 2.6.х) по-прежнему держать IDE
вкомпилированным в ядро? 
Предлагается вынести его в отдельный модуль.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [d-kernel] Вынос IDE в модуль

[Sergey Vlasov]

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

On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote:
> А какие у нас остались аргументы в пользу того,
> чтобы (для ядра 2.6.х) по-прежнему держать IDE
> вкомпилированным в ядро? 
> Предлагается вынести его в отдельный модуль.

Это уже давно предлагается; основная сложность тут в написании
соответствующей поддержки для mkinitrd.

Сейчас у меня есть вроде бы работающий кусок, определяющий набор модулей
для PCI IDE, обнаруженных текущим ядром.  Правда, в случае, если в старом
ядре не было нужного драйвера, из-за чего использовался ide-generic,
появившийся в новом ядре драйвер не будет использован автоматически.
Видимо, стоит ещё добавить поиск PCI IDE, которые могут оказаться на
ide-generic, по классу.

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

Re: [d-kernel] Вынос IDE в модуль

[Vitaly Lipatov]

On Monday 07 February 2005 12:42, Sergey Vlasov wrote:
> On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote:
> > А какие у нас остались аргументы в пользу того,
> > чтобы (для ядра 2.6.х) по-прежнему держать IDE
> > вкомпилированным в ядро?
> > Предлагается вынести его в отдельный модуль.
>
> Это уже давно предлагается; основная сложность тут в написании
Куда FR повесить?
> соответствующей поддержки для mkinitrd.
Сейчас в initrd толком не пакуется поддержка soft raid и 
sata-контроллеров, так что всё равно надо. И с учётом 
приближающейся повсеместной миграции на sata, приоритеты для ide 
теряюсь смысл.
> Сейчас у меня есть вроде бы работающий кусок, определяющий
> набор модулей для PCI IDE, обнаруженных текущим ядром. 
Здорово. А для sata?
> Правда, в случае, если в старом ядре не было нужного драйвера,
> из-за чего использовался ide-generic, появившийся в новом ядре
Да, это я ловил, делая initrd для ядра 2.6 из 2.4
Но может это исправляется просто загрузочным CD с ядром 2.6?
> драйвер не будет использован автоматически. Видимо, стоит ещё
> добавить поиск PCI IDE, которые могут оказаться на
> ide-generic, по классу.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [d-kernel] Вынос IDE в модуль

[Sergey Vlasov]

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

On Tue, Feb 08, 2005 at 01:47:55AM +0300, Vitaly Lipatov wrote:
> On Monday 07 February 2005 12:42, Sergey Vlasov wrote:
> > On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote:
> > > А какие у нас остались аргументы в пользу того,
> > > чтобы (для ядра 2.6.х) по-прежнему держать IDE
> > > вкомпилированным в ядро?
> > > Предлагается вынести его в отдельный модуль.
> >
> > Это уже давно предлагается; основная сложность тут в написании
> Куда FR повесить?

В принципе уже не надо ;)

> > соответствующей поддержки для mkinitrd.
> Сейчас в initrd толком не пакуется поддержка soft raid и 
> sata-контроллеров, так что всё равно надо. И с учётом 
> приближающейся повсеместной миграции на sata, приоритеты для ide 
> теряюсь смысл.
> > Сейчас у меня есть вроде бы работающий кусок, определяющий
> > набор модулей для PCI IDE, обнаруженных текущим ядром. 
> Здорово. А для sata?

Поскольку драйверы SATA сейчас работают через эмуляцию SCSI, для них
используется тот же способ, что и для SCSI - загрузка модулей,
перечисленных в (alias|probeall) scsi_hostadapter ... в /etc/modules.conf.

> > Правда, в случае, если в старом ядре не было нужного драйвера,
> > из-за чего использовался ide-generic, появившийся в новом ядре
> Да, это я ловил, делая initrd для ядра 2.6 из 2.4
> Но может это исправляется просто загрузочным CD с ядром 2.6?

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

> > драйвер не будет использован автоматически. Видимо, стоит ещё
> > добавить поиск PCI IDE, которые могут оказаться на
> > ide-generic, по классу.

Тут вылезает ещё одна проблема - на таких PCI ID могут висеть ещё и
драйверы libata.  А уж то, что сотворили в свежем sata_nv - вообще ужас:

2005/01/20 achew      | 	{ PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
2005/01/20 achew      | 		PCI_ANY_ID, PCI_ANY_ID,
2005/01/20 achew      | 		PCI_CLASS_STORAGE_IDE<<8, 0xffff00, GENERIC },

Т.е., этот модуль будет вытаскиваться при наличии _любого_ контроллера
IDE от nVidia, а дальше функция ->probe смотрит, похож ли этот контроллер
на SATA:

2005/01/20 achew      |         // Make sure this is a SATA controller by counting the number of bars
2005/01/20 achew      |         // (NVIDIA SATA controllers will always have six bars).  Otherwise,
2005/01/20 achew      |         // it's an IDE controller and we ignore it.
2005/01/20 achew      | 	for (bar=0; bar<6; bar++)
2005/01/20 achew      | 		if (pci_resource_start(pdev, bar) == 0)
2005/01/20 achew      | 			return -ENODEV;

По этому поводу приходит на ум только фильтрация по пути к модулю -
например, так: если в имени файла модуля или модулей, вытаскиваемых по
зависимостям, есть /kernel/drivers/scsi/ - это не драйвер IDE, и в этом
месте его загружать не надо.

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

Re: [d-kernel] ÷ÙÎÏÓ IDE × ÍÏÄÕÌØ

[Anton Farygin]

Sergey Vlasov wrote:

>On Tue, Feb 08, 2005 at 01:47:55AM +0300, Vitaly Lipatov wrote:
>  
>
>>On Monday 07 February 2005 12:42, Sergey Vlasov wrote:
>>    
>>
>>>On Sat, Feb 05, 2005 at 05:50:34PM +0300, Vitaly Lipatov wrote:
>>>      
>>>
>>>>А какие у нас остались аргументы в пользу того,
>>>>чтобы (для ядра 2.6.х) по-прежнему держать IDE
>>>>вкомпилированным в ядро?
>>>>Предлагается вынести его в отдельный модуль.
>>>>        
>>>>
>>>Это уже давно предлагается; основная сложность тут в написании
>>>      
>>>
>>Куда FR повесить?
>>    
>>
>
>В принципе уже не надо ;)
>
>  
>
>>>соответствующей поддержки для mkinitrd.
>>>      
>>>
>>Сейчас в initrd толком не пакуется поддержка soft raid и 
>>sata-контроллеров, так что всё равно надо. И с учётом 
>>приближающейся повсеместной миграции на sata, приоритеты для ide 
>>теряюсь смысл.
>>    
>>
>>>Сейчас у меня есть вроде бы работающий кусок, определяющий
>>>набор модулей для PCI IDE, обнаруженных текущим ядром. 
>>>      
>>>
>>Здорово. А для sata?
>>    
>>
>
>Поскольку драйверы SATA сейчас работают через эмуляцию SCSI, для них
>используется тот же способ, что и для SCSI - загрузка модулей,
>перечисленных в (alias|probeall) scsi_hostadapter ... в /etc/modules.conf.
>
>  
>
>>>Правда, в случае, если в старом ядре не было нужного драйвера,
>>>из-за чего использовался ide-generic, появившийся в новом ядре
>>>      
>>>
>>Да, это я ловил, делая initrd для ядра 2.6 из 2.4
>>Но может это исправляется просто загрузочным CD с ядром 2.6?
>>    
>>
>
>То же самое вылезет и при обновлении ядра, если в предыдущей версии не
>было нужного драйвера.  Так что всё равно придётся что-то делать.
>
>  
>
>>>драйвер не будет использован автоматически. Видимо, стоит ещё
>>>добавить поиск PCI IDE, которые могут оказаться на
>>>ide-generic, по классу.
>>>      
>>>
>
>Тут вылезает ещё одна проблема - на таких PCI ID могут висеть ещё и
>драйверы libata.  А уж то, что сотворили в свежем sata_nv - вообще ужас:
>
>2005/01/20 achew      | 	{ PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
>2005/01/20 achew      | 		PCI_ANY_ID, PCI_ANY_ID,
>2005/01/20 achew      | 		PCI_CLASS_STORAGE_IDE<<8, 0xffff00, GENERIC },
>
>Т.е., этот модуль будет вытаскиваться при наличии _любого_ контроллера
>IDE от nVidia, а дальше функция ->probe смотрит, похож ли этот контроллер
>на SATA:
>
>2005/01/20 achew      |         // Make sure this is a SATA controller by counting the number of bars
>2005/01/20 achew      |         // (NVIDIA SATA controllers will always have six bars).  Otherwise,
>2005/01/20 achew      |         // it's an IDE controller and we ignore it.
>2005/01/20 achew      | 	for (bar=0; bar<6; bar++)
>2005/01/20 achew      | 		if (pci_resource_start(pdev, bar) == 0)
>2005/01/20 achew      | 			return -ENODEV;
>
>По этому поводу приходит на ум только фильтрация по пути к модулю -
>например, так: если в имени файла модуля или модулей, вытаскиваемых по
>зависимостям, есть /kernel/drivers/scsi/ - это не драйвер IDE, и в этом
>месте его загружать не надо.
>  
>
Мне все-таки кажется что надо расширять функциональность hwdatabase.

Rgds,
Rider