From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3F6DC20C.3020204@altlinux.com> Date: Sun, 21 Sep 2003 19:21:48 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030710 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development Subject: Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus References: <20030806200424.5fc9069b.vsu@altlinux.ru> <20030921132950.18884293.vsu@altlinux.ru> <3F6D7984.1020608@altlinux.com> <20030921154430.6bc5f24a.vsu@altlinux.ru> <20030921120523.GA13035@sam-solutions.net> <3F6D968A.6090605@altlinux.com> <20030921123058.GB13035@sam-solutions.net> In-Reply-To: <20030921123058.GB13035@sam-solutions.net> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0E4488C88984C5C6ABB1E14" Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2003 15:21:51 -0000 Archived-At: List-Archive: List-Post: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0E4488C88984C5C6ABB1E14 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit 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 --------------enigD0E4488C88984C5C6ABB1E14 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/bcIMqohfd2vlwKsRAhVaAKC5QXCVnrxVgEQKLGTGadb1hItGBQCgtcGT TlQnMEHb8aQpY8RksugE69w= =lgYy -----END PGP SIGNATURE----- --------------enigD0E4488C88984C5C6ABB1E14--