[devel] Re: UQ: hotplugs vs two sound cards

[Michael Shigorin]

PreScriptum:

- hotplug/pci предлагается отложить на Master 3.0;
- для Master 2.4 предлагается использовать замороженный по
  состоянию на Compact 2.3 или Sisyphus-current kudzu.

Соображения -- ниже.

On Thu, Jun 10, 2004 at 11:08:32AM +0400, Anton Farygin wrote:
> >Тут сконфигурирована смесь (snd-emu10k1 + nvaudio) -- мне так
> >sound-scripts интереснее было крутить; правда, hotplug все
> >равно грузит snd-intel8x0 -- что вполне понятно, но: sudo grep
> >-r snd-intel8x0 /etc/mod* находит совпадения в только в
> >/etc/modprobe.conf-out, и этот искуственный интеллект
> >напрягает.
> Это не искусственный интелект..

Нет.  Это неестественный интеллект в худшем смысле этого слова, и
смотри почему.

У нас в итоге смешиваются:

- желательно интерактивная настройка оборудования и
- желательно неинтерактивная настройка оборудования.

Первое -- это сетевые интерфейсы, принтеры, прочая периферия, где
надо спросить пользователя (и которые _наиболее_ типично, хотя
необязательно, подключены более стационарно, чем пять раз на
ребут), а второе -- это целевая "аудитория" покойного сервиса usb
в первую очередь.

Которая местами пересекается с первой, но не в весьма
распространенной категории usb-storage.

Так вот.

Что происходит, когда на систему без сетевых карт добавляется
обычная поддерживаемая PCI-карта?  Раньше kudzu при загрузке или
с пинка писал modules.conf и дергал настраивалку.  Что теперь?

Что происходит, когда меняется видеокарта?

Что происходит, когда добавляется вторая звуковая карта
(классический пример -- к первой набортной)?

Что происходит, когда два PCI-устройства одного класса меняются
слотами?

Что происходит, когда к PCI ethernet добавляем USB- и
PCMCIA-ethernet? (в смысле неслетания связи через уже имеющийся)

И это мы еще не думаем, а что происходит, если добавляются
не-PCI/PCMCIA/USB, но _уже_ поддерживаемые устройства вроде
ISA PnP звука/модема. (между прочим, такие SB16 в Master 2.2
собраны и у меня было минимум две жалобы на это -- т.е. это не то
железо, про которое _уже_ можно забыть)

Про умеренно тонкие настройки вроде параметров модулей тоже пока
молчим.

> посмотри внимательно на код pci.rc и pci.agent.

Смотрел по диагонали, пока думал, где ж ошибка.  Потом понял, что
не в коде дело, а в подходе.

> Там загружаются модули, которые находятся через pciscan, если
> pciscan ничего не нашел, то идет загрузка модулей согласно
> /lib/modules/<kernel>/modules.pcimap.
> Ну и в такой схеме естественно все то, что ты прописал в
> modules.conf - игнорируется.

Ты думаешь, такой дистрибутив выживет на рынке, даже если успеем
отлизать хотя бы половину вылезших багов?

Автоматика, которая хотя бы уже проверена -- это Microsoft(R)
Windows(TM), и тут ты с ними за полгода не потягаешься ну никак.

И то -- (гипер)интерактивна, а не наоборот -- все молча.

kudzu, который мы с тобой дружно не любим -- автоматика, которая
может и не так, но проверена и работает на более широком ареале
_критичных_ ситуаций, включая пресловутые последовательные мышки.

> Как это исправить ? Вопрос хороший, я пока что этого не знаю.

Так может перед тем как ломать -- обдумать, что именно строить, и
не брать на себя исключительное бремя ответственности?

> В принципе можно сделать /etc/pciscan.d/, куда класть
> дополнительные конфиги для таких случаев, как у тебя
> (самосборные модули).

Брр.

trickster:~> sudo rpm -qf /lib/modules/2.4.26-std-up-alt2/nvidia-nforce/nvaudio.o
kernel-modules-nvidia-nforce-std-up-1.0.0261-alt12.2

Другое дело, что могут же быть и самосборные... или "обратитесь к
производителю"? ;-)

> В общем - если есть идеи, то я готов их выслушать в bugzilla.

Идея есть одна -- сказать, что hotplug::pci -- это ALM3 timeline
и не пытаться родить гибрид ужа с ежом -- дистрибутив на 2.4 с
инсталятором на 2.4, в котором из инсталятора выкинуты его
основные ценности -- хоть как-то делающие рабочий
/etc/modules.conf куски, потому как на modules.conf мы в рантайме
все равно забиваем.

Подумай сам, сколько горя будет из-за:

- неработающих последовательных мышей;
- неподъемных без sndconfig isapnp-звуковушек;
- "неотключаемого kudzu" или "неработающего usb" (без вариантов);
- прочих ляпов, которые всегда остаются при изменениях в
  последний момент.

Я понимаю, что поддерживать kudzu/ldetect-lst -- боль и что ляпов
там остается все равно NNN, но что мешает хотя бы заморозить их
на уровне ALC2.3 с минимальными изменениями (ведь переворотов не
было)?

При этом параллельно спокойно развивать hotplug, в т.ч.
PCI-часть (включив ее локально в явном виде) и к 3.0 получить
более взвешенный баланс этой экосистемы, которая, как видим на
примере *-scripts, на hotplug не заканчивается.

> >В общем, что делать и кто виноват? (спрашиваю в т.ч. как
> >майнтейнер sound-scripts, которого первым будут бить за
> >неподобство с двумя звуковыми, да и не только с двумя)
> На 2.6 ядре sound-scripts надо отправлять в /dev/null, перенося
> всю функциональность в sound.agent hotplug'а. Это более
> правильное решение.

Не спорю и обдумываю это минимум полгода, начитавшись Takashi
Iwai (собственно, как сел пилить sound-scripts, так и).

> Однако оно не работает на 2.4 ядре и это можно будет делать
> только тогда, когда мы забудем про существование ядра 2.4.

И ISA PnP (в смысле, официально скажем "а ну марш в магазин, неча
свое барахло под наш линукс подставлять").

Беда в том, что это, с позволения сказать, anti-hotplugged
hardware (которое долго и/или рискованно детектится или вообще
конфигурируется вручную) будет жить даже дольше, чем нужно
поддерживать ядро 2.4.

И "мы", как уже не раз отмечалось -- это еще не вся аудитория
дистрибутива, или в нем нет смысла.  А есть люди, которые 2.2 еще
пользуют или с 2.0 не так давно слезли...

PS: pilot@ пока пришел к выводу, что на сейчас возможно только
игнорировать запуски ifup из hotplug.  Я тоже могу сделать
аналогичный объезд -- в sound::start() молча выгружать звуковые
модули и при этом все будет работать, как ожидается -- но это же
не дело.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040610/229f61e1/attachment-0001.bin>