Alexander Bokovoy пишет: > On Sun, Sep 21, 2003 at 04:16:10PM +0400, Anton Farygin wrote: > >>>Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы >>>интегрировать, наконец, имеющиеся наработки по автоматической >>>идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и >>>что хотелось бы обобщить на весь проект: >>> >>> - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с >>> полным выносом как SCSI, так и IDE в модули. Работает и в случае >>> двух-трех ходовок (загрузка специальных модулей чипсетов, после чего >>> ide-probe начинает видеть контроллер) и в обычных случаях. Все правки >>> для mkinitrd/ядра есть; >> >>Можно будет начать примерно недели через две. >> >> >>> - автоматическое детектирование PCI устройств и загрузка драйверов -- >>> тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/ >>> и развязывание зависимостей на kudzu -- для PCI-устройств kudzu >>> является стрельбой из пушки, можно сделать все проще (скрипт pcidetect, >>> работающий по этой схеме, уже есть, работает для сети и аналогичных >>> устройств), да и расстановка приоритетов привязки драйверов не >>> помешает (важно для мульти-хостовых серверов, где имена сетевых >>> интерфейсов иногда нужно жестко закреплять за драйверами); >> >>Аналогично... только там есть некоторая проблема: нужно будет еще >>создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), >>для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis >>например), для некоторых - прописывать дополнительные конфигурационные >>файлы (или запускать дополнительные программы)... и т.д. > > Это -- не проблема. Что касается загрузки нескольких драйверов, то: > > - нужно отказываться от использования insmod, как класс, в пользу > modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd > при загрузке чипсетов IDE, с modprobe они работают без проблем. Тогда нужно будет решать как грузить драйвера аля pctel, у которых две части и modprobe их грузить нельзя принципиально - они все провайдят одинаковый набор функций. > > - это достижимо средствами modutils без проблем -- специальные команды > есть (above/below). > > Вообщем, есть уже готовый аппарат в modutils, который все требуемое > обеспечивает -- и запуск программ, и вытягивание стеков модулей, и > последовательное опробывание цепочки драйверов. Недельки через две попробуем. > > >>> - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют >>> (есть специальные модули), с нотификацией обработчика событий в >>> user-space (наработки есть). Для этого момента хотелось бы >>> унифицировать >>> интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось >>> в едином ключе; >> >>Это интересно... можно попробовать. Но тоже недельки через две... >> >> >>> - создание базы типовых конфигураций для sensors для того, чтобы более >>> точно детектировать их и устанавливать конфигурации по умолчанию; >>> возможно, появление механизма ограничений перебираемых конфигураций -- >>> для OEM-вариантов, где могут быть ограниченные вариации платформы. >>> >> >>Это меня если честно - мало интересует, ибо 1) sensors на многих машинах >>сильно глючат 2) сам не пользуюсь ;-) > > Помимо тебя, Антон, и нас, всех остальных разработчиков, есть еще пользователи. :) > Вот именно для этого, чтобы работало, а не глючило, потенциальные конфигурации > необходимо определять, по возможности автоматически. Шансы для этого по отношению > к распространенным чипсетам есть, нужно их использовать. Пусть и не все покроем, > но на нормальных машинах сможем обеспечить приемлемый уровень покрытия. Особенно > это важно для современных десктопов и ноутбуков. Да, безусловно. > > Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку > исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей > Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с > исправленными DSDT с acpi.sf.net. с ACPI все хорошо, но работающего suspend'а на ACPI я еще не видел ;-( Rgds, Rider