From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <40C8AC75.6060401@altlinux.com> Date: Thu, 10 Jun 2004 22:46:13 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.6) Gecko/20040310 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Michael Shigorin References: <40B481BF.2060409@altlinux.com> <20040601115852.GE11462@osdn.org.ua> <20040601122935.GC786@master.mivlgu.local> <20040610064505.GB29312@osdn.org.ua> <40C808F0.1020606@altlinux.com> <20040610181841.GQ29306@osdn.org.ua> In-Reply-To: <20040610181841.GQ29306@osdn.org.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: devel@altlinux.ru Subject: [devel] Re: UQ: hotplugs vs two sound cards X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:46:16 -0000 Archived-At: List-Archive: List-Post: 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//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() молча выгружать звуковые > модули и при этом все будет работать, как ожидается -- но это же > не дело. >