Alexander Bokovoy пишет:
> On Sun, Sep 21, 2003 at 03:44:30PM +0400, Sergey Vlasov wrote:
> 
>>>>>SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
>>>>>SV>  включающий SMBus при обработке PCI quirks. Это работает, но
>>>>>SV>  требует пересборки ядра для добавления новых идентификаторов.
>>>>>
>>>>>Я бы пока предпочел первый вариант.  
>>>>
>>>>
>>>>А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...
>>>
>>>Взять взять...
>>
>>Положил в kernel-fix-drivers-pci. Прямо сейчас проверить не на чем, но
>>предыдущая версия у меня на P4PE работала.
> 
> OK.
> 
> 
>>>я как раз завтра собираюсь собрать ядрышко более новое из CVS.
>>
>>Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
>>сломал поддержку AGP2 :-(
>>
>>Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
>>откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)
> 
> В почте, по-моему, этого не упоминалось.
> 
> 
>>PS: Интернет провели, вроде сегодня даже не глючит :-)
> 
> Отлично!
> 
> Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы
> интегрировать, наконец, имеющиеся наработки по автоматической
> идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и
> что хотелось бы обобщить на весь проект:
> 
>   - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с
>     полным выносом как SCSI, так и IDE в модули. Работает и в случае
>     двух-трех ходовок (загрузка специальных модулей чипсетов, после чего
>     ide-probe начинает видеть контроллер) и в обычных случаях. Все правки
>     для mkinitrd/ядра есть;

Можно будет начать примерно недели через две.

> 
>   - автоматическое детектирование PCI устройств и загрузка драйверов --
>     тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
>     и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
>     является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
>     работающий по этой схеме, уже есть, работает для сети и аналогичных
>     устройств), да и расстановка приоритетов привязки драйверов не
>     помешает (важно для мульти-хостовых серверов, где имена сетевых
>     интерфейсов иногда нужно жестко закреплять за драйверами);

Аналогично... только там есть некоторая проблема: нужно будет еще 
создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), 
для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
например), для некоторых - прописывать дополнительные конфигурационные 
файлы (или запускать дополнительные программы)... и т.д.

> 
>   - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют
>     (есть специальные модули), с нотификацией обработчика событий в
>     user-space (наработки есть). Для этого момента хотелось бы унифицировать
>     интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось
>     в едином ключе;

Это интересно... можно попробовать. Но тоже недельки через две...

> 
>   - создание базы типовых конфигураций для sensors для того, чтобы более
>     точно детектировать их и устанавливать конфигурации по умолчанию;
>     возможно, появление механизма ограничений перебираемых конфигураций --
>     для OEM-вариантов, где могут быть ограниченные вариации платформы.
>   

Это меня если честно - мало интересует, ибо 1) sensors на многих машинах 
сильно глючат 2) сам не пользуюсь ;-)

Rgds,
Rider