From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 29 Nov 2004 17:45:29 +0200 From: Michael Shigorin To: devel@altlinux.ru Message-ID: <20041129154529.GY1587@osdn.org.ua> Mail-Followup-To: devel@altlinux.ru References: <41AB2704.3030106@altlinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41AB2704.3030106@altlinux.com> User-Agent: Mutt/1.4.2.1i Subject: [devel] Re: =?koi8-r?b?5NfBINDPxMjPxMEgyyDWydrOySDJzMkgy8HLIMTFzMHU2CDQ?= =?koi8-r?b?zyDExcbPzNTV?= 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: Mon, 29 Nov 2004 15:45:38 -0000 Archived-At: List-Archive: List-Post: On Mon, Nov 29, 2004 at 04:41:24PM +0300, Anton Farygin wrote: > Возник такой у нас с Pilot'ом интересный спорный вопрос. > Просьба конструктивно и _кратко_ на него ответить: > на ваш взгляд: сразу после установки системы после первой > загрузки должны ли быть видны доступные в системе сетевые > интерфейсы по команде ifconfig -a _до этапа настройки сети > (через конфигуратор) пользователем_ ? > Можно просто сказать: да/нет. 1) да, это неважно; 2) нет, это неважно. :) IMCO это был неверный вопрос, любой ответ на который ровным счётом ничего не значит. Попробую по возможности объективно осветить проблему; в конце прилагается также чуточку пофильтрованный по релевантности лог. Вопрос ~~~~~~ Где и как определяется точная программная конфигурация аппаратного обеспечения (по умолчанию и специфическая)? Обсуждение ~~~~~~~~~~ Существует два "полярных" варианта -- "всё настроено автоматически" и "всё настраивается руками". Первое -- это Plug'n'Play и на Linux в данный момент -- hotplug. (в сторону: а есть ли hotplay? :) Второе -- это $EDITOR и сокровенное знание, что и где именно править помимо знания значений, которые в конфигурацию должны попасть. Вменяемые системы находятся где-то посредине -- дают возможность реализовать промежуточные варианты, от минимального вмешательства (например, указание значения конфигурации) до минимальной автоматизации (например, загрузка модуля, соответствующего заданному PCI-устройству). При этом у нас есть несколько типичных точек, приводящих к изменениям состояния этой конфигурации: 1) первичная установка и настройка операционной среды (в данный момент -- mdk installer, в перспективе это обеспечивается alterator); 2) настройка добавленного в процессе эксплуатации системы оборудования; 3) ручное изменение конфигурации администратором системы. При этом каждый из этих пунктов состоит из некоторой автоматической настройки (с использованием значений или соответствий по умолчанию) и некоторой ручной деятельности (как минимум согласие, обычно инициирование, подчас -- ввод значений, которые не могут быть определены автоматически). Как правило, случаи с одним устройством заданного класса не приводят к проблемам, т.к. система не предоставляет выбора по причине его объективного отсутствия (разве что "отключить вообще" как альтернатива "чтоб работало"). Проблемы начинаются с "размножением" устройств одного класса и невозможностью автоматически определить соображения владельца аппаратного обеспечения по части того, как именно оно должно работать. Соображения ~~~~~~~~~~~ В идеале система не должна _требовать_ что-либо настраивать вручную, но если администратор усматривает в этом необходимость -- надо предоставить средства внесения и учёта изменений (хороший пример -- control(8)). Для звуковых чипов _частичным_ (ALSA-only) решением является использование параметра модуля "index" (см. ссылки); для сетевых интерфейсов -- nameif/ifrename (насколько понимаю). Для драйверов другого аппаратного обечпечения такие регуляторы могут как наличествовать, так и отсутствовать; при этом общая проблема в каждом конкретном случае решается разными средствами (отчасти? из-за разных источников идентификационной ниформации). Пример ~~~~~~ Рассмотрим два класса аппаратного обеспечения, которые уже создают проблемы на пару с hotplug в случае попытки управлять ими с его помощью -- сетевые интерфейсы и звуковые платы. В обоих случаях точное соответствие логических и физических устройств обычно критично и не должно зависеть от изменений порядка сканирования PCI-шины ядром или иной погоды на Марсе: изменение порядка логических устройств приводит к тому, что сигнал подаётся не на тот разъём, где его ждут. В случае сетевого интерфейса это может привести к "странным" (плохо описываемым и решаемым поддержкой) проблемам в сочетании с файрволами, ограничением доступа по MAC и т.д.; в случае звуковой платы -- в лучшем случае к тому, что для воспроизведения будет использоваться низкокачественное устройство вместо высококачественного (и то лишь после манипуляций с проводами), в худшем же проснувшийся в три часа ночи стояк может надолго лишить майнтейнера способности заниматься пакетами что в наушниках, что без них. При этом для сетевых интерфейсов ситуация усложняется тем, что довольно распространено применение однотипных сетевых карт, которые работают на одном драйвере (стоит учитывать в п.2). Возможно, встроенные звуковые карты "в среднем" получают более низкие идентификаторы на шине и склонны становиться первым логическим устройством в системе, которое по умолчанию и будут использовать программы, выводящие звук -- характер жалоб сводится к "играет через встроенную, а не нормальную". Выводы ~~~~~~ Основная проблема, которая может возникнуть -- не техническая: учёт мнения человека. Обычно её решают созданием конфигураторов. В отличие от rider@ мы с pilot@ считаем, что человеку, который настраивает систему без конфигуратора, лишний modprobe не будет проблемой (если он делает это N-й раз -- значит, это можно автоматизировать на этапе создания иных настроек по умолчанию для заданного случая -- например, livecd первой стадии нового инсталятора). При этом есть мнение, что решение частной проблемы разработчика (загрузка всех соответствующих обнаруженному, в т.ч. сетевому железу модулей) слишком общими средствами (возврат к такому поведению по умолчанию) затруднит тестирование подсистемы, которой оно также требуется (etcnet) в силу банального роста прикладных неудобств для администраторов, которые и так должны быть чем-то мотивированы, чтобы её тестировать, да ещё и на ядре 2.6. Попросту говоря, перетыкание кабелей это тестирование сведёт к нулю. Ссылки ~~~~~~ Предыдущее обсуждение вопроса (включая отношение пользователей к излишней жёсткости системы по части соответствия): http://lists.altlinux.ru/pipermail/sisyphus/2004-June/041781.html http://lists.altlinux.ru/pipermail/community/2003-September/098147.html http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041698.html https://bugzilla.altlinux.org/show_bug.cgi?id=4668 https://bugzilla.altlinux.org/show_bug.cgi?id=3487 https://bugzilla.altlinux.org/show_bug.cgi?id=3528 https://bugzilla.altlinux.org/show_bug.cgi?id=1802 Приложение ~~~~~~~~~~ rider: ну так что, ifconfig-то не спасёт gvy: ничего ты не понял ;-) * Pilot тоже ничего не понял rider, а конфигуратор сети планируется дёргать из инсталятора? тогда так, господа gvy: нет конечно. А зачем ? бишь поставили базовую систему, бутнулись в неё, что дальше? как зачем? нужна гуйня для конфигурации сети, выходит Pilot: да. Гуйня нужна. Но это - не дело инсталятора настраивать сеть. кто будет её писать? Pilot, это дело команды alterator Pilot: ну кроме нас некому rider: если будет, то в чём проблема и зачем размахивать ifconfig? Pilot: но прежде чем писать гуйню - нужно закончить баталии. Нужно определиться кто как и что будет грузить/настраивать я думал, всё уже давно определилось Pilot: да в том, что нет у меня гуйни. Я после загрузки хочу быстро получить доступ в сеть. Что может быть быстрее ifconfig ? rider: тебе 25-го нужо было приезжать в офис Pilot: да нет. Не определилось. В том то и дело. rider: хозяин-бырин барин Pilot: что будет если я сейчас включу в hotplug'е загрузку драйверов для сети ? много сломается ? rider: я не о тебе, а о других пользователях [skip] Pilot: не нужна - идем в /etc/libhw.conf и отключаем драйвер для конкретного сетевого устройства rider: давай спросим общественного мнения, я уже доводы исчерпал, хотя мнения не изменил Pilot: вот тебе другой пример: новичок поставил дистрибутив, загрузился и ему говорят о том, что бы настроить сеть нужно сменить IP адрес на интерфейсе (стандартный подход практически в любом UNIX). * lioka думает, что автосеть должна быть в отдельном пакете, не являющемся неотъемлемой частью сетевой подсистемы. ну и что? если вы об этом lioka: нет. До автосети мы еще доберемся ;-) не сменить, а назначить Pilot: хорошо. Назначить. и пусть себе назначает я ж не мешаю Pilot: да как он назначит, если: ifconfig eth0 его посылает, ибо 1) модуль не загружен 2) в /etc/modules.conf alias отсуствует о! rider, новичка пошлёт уже отсутствие конфигуратора :( * gvy не выдержал попытки решения проблемы на НЕ ТОМ уровне gvy: помолчи, ПОЖАЛУЙСТА! для этого один абзац жалко, что ли? написать, что такое lspcidrake и что такое modprobe Pilot: а зачем ? Pilot: когда можно все сделать автоматически вместо того, чтобы зашоривать, подсказать ему нормальный путь конфигурации оборудования, если инстяллятор не постарался Pilot: и плюс к этому _безусловно_ - нормальный путь конфигурации rider: ты придумываешь какой-то холодный ядерный синтез для чайников за 5 минут давайте или по-простому или по-пацански Pilot: понимаешь, если бы во всех Linux'ах настройка аппаратной части была одинакова - я бы с тобой согласился Pilot: а так - я не согласен. Проведем блиц-опрос в devel@ Pilot: нет, мы говорим о пользователях, которые пользуются системой. как там в RH, мне по барабану, я хочу сделать лучше rider: проведём. только мои комментарии тоже должны быть в опросе Pilot: я написал уже письмо - посмотри Pilot: я задал вопрос просто: на ваш взгляд: сразу после установки системы после первой загрузки должны ли быть видны доступные в системе сетевые интерфейсы по команде ifconfig -a _до этапа настройки сети (через конфигуратор) пользователем_ ? * Pilot . o O (без меня меня женили, развели и посадили) Pilot: вообще речь идет не только о тебе [pause] gvy: ну да. Но опять же - это же не вопрос sound-scripts. Просто hotplug будет работать так же как и всегда - спокойно грузить драйвера. А sound.agent - менять индекс, если это надо. rider, ыыы... в смысле менять индекс? после загрузки модуля этот индекс до фени rider: наконец-то ты озвучил идею! rider, давай я в devel попробую схему проблемы очертить? gvy: ага. тогда этим будет заниматься конфигуратор, настраивающий libhw ВОООТ! raorn: достаточно, если eth1 есть rider, именно это я уже час и пытаюсь сказать -- железо (драйверы) без конфигурации никому не нужны, кроме нас, разработчиков :) а мы можем дефолт данной конкретной сборки под себя подогнать gvy: не всегда. В большинстве случаев дефолтные конфигурации срабатывают rider, в большинстве -- да. rider: я подумаю, как предметно ответить на разделение по крайней мере хорошие дефолтные конфигурации Pilot: ok. gvy: ну да. а все остальное - действительно дело рук конфигуратора. PS: меня опять отвлекли где-то в районе перехода к примерам. :E -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/