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

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

[Michael Shigorin]

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

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/

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

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

[Anton Farygin]

Michael Shigorin пишет:
> PreScriptum:
> 
> - hotplug/pci предлагается отложить на Master 3.0;

hotplug/pci работает только на ядре 2.6. Для ядра 2.4 он не выполняется.

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

не получится.. 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 и дергал настраивалку.  Что теперь?

Тоже самое в ядре 2.4

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

Аналогично.

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

На ядре 2.4 - аналогично. На ядре 2.6 - все по другому.

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

Ничего.

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

Зпускается hotplug или cardbus
> 
> И это мы еще не думаем, а что происходит, если добавляются
> не-PCI/PCMCIA/USB, но _уже_ поддерживаемые устройства вроде
> ISA PnP звука/модема. (между прочим, такие SB16 в Master 2.2
> собраны и у меня было минимум две жалобы на это -- т.е. это не то
> железо, про которое _уже_ можно забыть)
> 
> Про умеренно тонкие настройки вроде параметров модулей тоже пока
> молчим.
> 
> 
>>посмотри внимательно на код pci.rc и pci.agent.
> 
> 
> Смотрел по диагонали, пока думал, где ж ошибка.  Потом понял, что
> не в коде дело, а в подходе.

Неверно.

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

Выживет. Ядро 2.6 - экспериментальное.

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

На ядре 2.4 - да. На ядре 2.6 kudzu не работает _совсем_.

Если тебе реально интересно что такое kudzu - посмотри на федору - там 
его уже переписали _исключительно_ для ядра 2.6. Т.е. - обновлять нам 
его нельзя.

> 
> 
>>Как это исправить ? Вопрос хороший, я пока что этого не знаю.
> 
> 
> Так может перед тем как ломать -- обдумать, что именно строить, и
> не брать на себя исключительное бремя ответственности?

Думай. Я уже все обдумал.

> 
> 
>>В принципе можно сделать /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

Это ядро 2.4. Как ты умудрился запустить hotplug pci на ядре 2.4 ?

> 
> Другое дело, что могут же быть и самосборные... или "обратитесь к
> производителю"? ;-)
> 
> 
>>В общем - если есть идеи, то я готов их выслушать в 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() молча выгружать звуковые
> модули и при этом все будет работать, как ожидается -- но это же
> не дело.
> 

[devel] Re: UQ: hotplug vs two sound/network cards

[Michael Shigorin]

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

On Thu, Jun 10, 2004 at 10:46:13PM +0400, Anton Farygin wrote:
> >- hotplug/pci предлагается отложить на Master 3.0;
> hotplug/pci работает только на ядре 2.6. Для ядра 2.4 он не
> выполняется.

При этом у нас получается _очень_ разная среда выполнения для 2.4
и 2.6 на одинаковом железе... правда, уже забылся переезд с 2.2
на 2.4.

Принято.

> >- для Master 2.4 предлагается использовать замороженный по
> >  состоянию на Compact 2.3 или Sisyphus-current kudzu.
> не получится.. kudzu придется править в любом случае.

Мне (по твоим письмам в devel@ и sisyphus@) показалось, что ты
его собираешься из ALM2.4 изгнать.  Моя проблема была в этом.

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

Верно, просто ты до этого еще не добрался.  Будешь ковырять
net-scripts -- доберешься :-)

(только не ограничивайся случаем ноутбуков с одним встроенным
или наоборот -- одним PCMCIA-эзернетом, надо сразу иметь в виду и
обтыканные разным или одинаковым железом маршрутизаторы)

> На ядре 2.4 - да. На ядре 2.6 kudzu не работает _совсем_.
> Если тебе реально интересно что такое kudzu - посмотри на
> федору - там его уже переписали _исключительно_ для ядра 2.6.
> Т.е. - обновлять нам его нельзя.

ACK

> >>В принципе можно сделать /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
> Это ядро 2.4. Как ты умудрился запустить hotplug pci на ядре 2.4 ?

Никак -- это было к тому, что в modules.conf сказано nvaudio
(вторым), а звгрузился нигде очевидно не указанный snd-intel8x0
:-)

Вопрос снят, ты ответил выше.

> Ты код смотрел ?  Дальше я не читаю.

Да, смотрел.  Почитай, т.к. на 2.6 все равно актуально, хотя
рёберность проблемы резко снижается.

Главная из непрочитанного тобой мысль -- дифференциация по
"стоимости" детекта (его длительность, надежность,
неинтерактивность).  Хвост с pilot@ уже обсудили вроде.

[13dd]

> >При этом параллельно спокойно развивать 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/

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

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

[Denis Ovsienko]

> hotplug/pci работает только на ядре 2.6. Для ядра 2.4 он не выполняется.
Давайте разберёмся.
Если я запускаю modprobe <модуль-для-PCI-ethernet> и у меня срабатывает
ifup, то это hotplug/pci? Ядро 2.4

-- 
   DO4-UANIC

Re: [devel] Re: UQ: hotplug vs two sound/network cards

[Anton Farygin]

Michael Shigorin пишет:
> On Thu, Jun 10, 2004 at 10:46:13PM +0400, Anton Farygin wrote:
> 
>>>- hotplug/pci предлагается отложить на Master 3.0;
>>
>>hotplug/pci работает только на ядре 2.6. Для ядра 2.4 он не
>>выполняется.
> 
> 
> При этом у нас получается _очень_ разная среда выполнения для 2.4
> и 2.6 на одинаковом железе... правда, уже забылся переезд с 2.2
> на 2.4.
> 
> Принято.
> 
> 
>>>- для Master 2.4 предлагается использовать замороженный по
>>> состоянию на Compact 2.3 или Sisyphus-current kudzu.
>>
>>не получится.. kudzu придется править в любом случае.
> 
> 
> Мне (по твоим письмам в devel@ и sisyphus@) показалось, что ты
> его собираешься из ALM2.4 изгнать.  Моя проблема была в этом.

Изгнал бы, если бы было время... с огромным удовольствием. А теперь 
придется в нем делать заглушку для 2.6.
> 
> 
>>>Смотрел по диагонали, пока думал, где ж ошибка.  Потом понял,
>>>что не в коде дело, а в подходе.
>>
>>Неверно.
> 
> 
> Верно, просто ты до этого еще не добрался.  Будешь ковырять
> net-scripts -- доберешься :-)
> 
> (только не ограничивайся случаем ноутбуков с одним встроенным
> или наоборот -- одним PCMCIA-эзернетом, надо сразу иметь в виду и
> обтыканные разным или одинаковым железом маршрутизаторы)

Да, естественно.

> 
> 
>>На ядре 2.4 - да. На ядре 2.6 kudzu не работает _совсем_.
>>Если тебе реально интересно что такое kudzu - посмотри на
>>федору - там его уже переписали _исключительно_ для ядра 2.6.
>>Т.е. - обновлять нам его нельзя.
> 
> 
> ACK
> 
> 
>>>>В принципе можно сделать /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
>>
>>Это ядро 2.4. Как ты умудрился запустить hotplug pci на ядре 2.4 ?
> 
> 
> Никак -- это было к тому, что в modules.conf сказано nvaudio
> (вторым), а звгрузился нигде очевидно не указанный snd-intel8x0
> :-)

А оно работало ?

> 
> Вопрос снят, ты ответил выше.
> 
> 
>>Ты код смотрел ?  Дальше я не читаю.
> 
> 
> Да, смотрел.  Почитай, т.к. на 2.6 все равно актуально, хотя
> рёберность проблемы резко снижается.

На 2.6 других вариантов нет. Пока нет.

Rgds,
Rider

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

[Anton Farygin]

Denis Ovsienko пишет:
>>hotplug/pci работает только на ядре 2.6. Для ядра 2.4 он не выполняется.
> 
> Давайте разберёмся.
> Если я запускаю modprobe <модуль-для-PCI-ethernet> и у меня срабатывает
> ifup, то это hotplug/pci? Ядро 2.4
> 

Денис, ты путаешь стартовые скрипты и среду выполнения.

В загруженной системе для новых сетевых устройств после modprobe 
_всегда_ пытается запустится ifup.

Хотя, опять же - на 2.4 я этого не проверял, может быть кто-то 
подскажет, есть ли hotplug.network на 2.4 ядре ?

Rgds,
Rider

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

[Denis Ovsienko]

> > Если я запускаю modprobe <модуль-для-PCI-ethernet> и у меня срабатывает
> > ifup, то это hotplug/pci? Ядро 2.4
> Денис, ты путаешь стартовые скрипты и среду выполнения.
Возможно. Всё-таки да или нет?

> В загруженной системе для новых сетевых устройств после modprobe
> _всегда_ пытается запустится ifup.
В какой не пытается?

> Хотя, опять же - на 2.4 я этого не проверял, может быть кто-то
> подскажет, есть ли hotplug.network на 2.4 ядре ?
Не знаю, как называется, поэтому и спрашиваю. Но факт описанной реакции
есть.

-- 
    DO4-UANIC

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

[Anton Farygin]

Denis Ovsienko пишет:
>>>Если я запускаю modprobe <модуль-для-PCI-ethernet> и у меня срабатывает
>>>ifup, то это hotplug/pci? Ядро 2.4
>>
>>Денис, ты путаешь стартовые скрипты и среду выполнения.
> 
> Возможно. Всё-таки да или нет?

Угу.

> 
> 
>>В загруженной системе для новых сетевых устройств после modprobe
>>_всегда_ пытается запустится ifup.
> 
> В какой не пытается?

В незагруженной ;-)

> 
> 
>>Хотя, опять же - на 2.4 я этого не проверял, может быть кто-то
>>подскажет, есть ли hotplug.network на 2.4 ядре ?
> 
> Не знаю, как называется, поэтому и спрашиваю. Но факт описанной реакции
> есть.
> 

Похоже что есть.. я сегодня посмотрю.

Rgds,
Rider

[devel] Re: UQ: hotplug vs two sound/network cards

[Michael Shigorin]

On Fri, Jun 11, 2004 at 10:04:09AM +0400, Anton Farygin wrote:
> >>Это ядро 2.4. Как ты умудрился запустить hotplug pci на ядре 2.4 ?
> >Никак -- это было к тому, что в modules.conf сказано nvaudio
> >(вторым), а звгрузился нигде очевидно не указанный
> >snd-intel8x0 :-)
> А оно работало ?

nvaudio?  Да (стерео; пару месяцев назад).  snd-intel8x0?  Тоже
да, если шнурок в его выход воткнуть :-)

> >Вопрос снят, ты ответил выше.
> >>Ты код смотрел ?  Дальше я не читаю.
> >Да, смотрел.  Почитай, т.к. на 2.6 все равно актуально, хотя
> >рёберность проблемы резко снижается.
> На 2.6 других вариантов нет. Пока нет.

Это понятно.

Другой вопрос -- куда вообще движется hotplug?  Ведь эти вопросы
явно возникли не только у нас и сейчас и явно должны были
предвидеться его авторами -- насчет противоречия hotplug unix-way
по части "автомат vs прибили_и_держится", которое особенно бьет
по дорогим/"невозможным" для автодетекта старым железкам и
администраторам. (*grin*)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: Q: hotplug vs two sound/network cards

[Michael Shigorin]

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

PreScriptum: можно отложить разборки с hotplug/pci на
post-Master, но тогда бы где написать, что поддержка Linux 2.6 в
ALM2.4 -- экспериментальная и известны такие-то проблемы.

Дальше -- скорее ссылки и обрывки, что-то голова не варит связать
в одну нить.  Но, с другой стороны, про противоречия
install/boot-timt настраивалок и "вечнозеленого" hotplug уже
кой-чего с pilot@, rider@ и vsu@ успели обсудить.

Пожалуй, самая ёмкая по степени суммирования ссылка:

http://lists.debian.org/debian-devel/2004/03/msg02466.html

On Fri, Jun 11, 2004 at 12:01:28PM +0300, Michael Shigorin wrote:
> Другой вопрос -- куда вообще движется hotplug?  Ведь эти вопросы
> явно возникли не только у нас и сейчас и явно должны были
> предвидеться его авторами -- насчет противоречия hotplug unix-way
> по части "автомат vs прибили_и_держится", которое особенно бьет
> по дорогим/"невозможным" для автодетекта старым железкам и
> администраторам. (*grin*)

http://lists.debian.org/debian-devel/2004/03/msg02479.html
http://lists.debian.org/debian-devel/2004/03/msg02409.html:

 > #2) ALSA's init script is executed after hotplug. The mixer
 > settings are
 > then "restored."
 Same issue: a init script is the wrong place to restore the mixer
 settings. Two correct places are /etc/modprobe.d/ or a script in
 /etc/dev.d/.

С этим и хотелось бы согласиться, но udev в Sisyphus не наблюдаю,
да и 2.6 у нас пока не дефолтное.

К этому по мелочи можно прибавить 

http://lists.debian.org/debian-devel/2004/03/msg02526.html
http://lists.debian.org/debian-devel/2004/03/msg02487.html:

 >> You need to add something like this in /etc/modprobe.d/ to
 >> make modprobe automatically load the OSS compatibility
 >> module.  (snd-mixer-oss is loaded anyway, does anybody know
 >> why?)
 >> install snd-pcm /sbin/modprobe --ignore-install snd-pcm &&
 >> /sbin/modprobe snd-pcm-oss
 > Isn't "above snd-pcm snd-pcm-oss" a simpler and clearer way to
 > express the same thing?
 Yes, but it's a modprobe (modutils) thing; modprobe
 (module-init-tools) doesn't support it.

Здесь накладывается на вопрос о будущем modutils vs hotplug,
который, помнится, был оставлен открытым до выяснения.

http://lists.debian.org/debian-devel/2004/03/msg02449.html:

 It's not at all clear to me that the hotplug framework is the
 right way to deal with automatically loading modules at boot
 time.  We have other schemes, such as /etc/modules, which work
 just as well, if not better.
	-- Theodore Ts'o

Followup с все тем же вопросом о порядке сетевых интерфейсов как
результате определения discover vs hotplug:
http://lists.debian.org/debian-devel/2004/03/msg02456.html

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240582:
предложение добавить "ручку" для выбора нужных задеваемых
компонент в hotplug.  В итоге он получил такой changelog entry:

---
Changes: 
 hotplug (0.0.20040329-3) unstable; urgency=low
 .
   * debian/hotplug.postinst
     preserve /etc/default/hotplug
     closes: Bug#240582
     anyway, current debconf configurations are deprecated, and
     I plan to delete these configuration variables in future.
     If you need something to load at start time, use /etc/modules instead.
   * debian/hotplug.postinst
     move deprecated /etc/hotplug/usb.usermap.local
     to /etc/hotplug/usb/local.usermap
     closes: Bug#241144
   * debian/hotplug.dirs: add /etc/hotplug/blacklist.d
     patches/014_load_drivers_blacklist_dir
      blacklist can be added by other packages, such as ALSA
     closes: Bug#241225
   * patches/013_load_drivers_check_module_dup
     patches/012_usb.agent_check_driver
     don't load drivers several times.
     closes: Bug#232909, Bug#237952, Bug#241326
   * patches/012_usb.rc_try_all_interfaces
      for TYPE=0/* USB devices, it will have several interfaces, so
      try them at startup time. problem reported by mat@nask.pl
   * patches/012_pci.rc_return_value
     backported
   * patches/011_hotplug.functions_quote_loaded
     backported
---

PS: еще момент, который, видимо, может иметь отношение к ALM2.4
и/или 3.x:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75015

(краткий смысл -- "отключите USB-звук перед установкой и добавьте
его _после_ установки, если дефолтной должна быть внутренняя
звуковая карта")

(здесь припоминается btaudio и опять идут мысли про
приоретизацию модулей)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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