[devel] пояснительная записка: etcnet, ifrename, udev и eth0

[Peter V. Saveliev]

В сообщении от Wednesday 31 October 2007 00:30:57 Denis Ovsienko написал(а):
> Приветствую всех.
>
> В последнее время (то есть после установки дома Desktop 4) я стал чаще
> читать рассылку devel@, а на sisyphus@ даже подписался. Должен
> признаться, некоторые вещи, которые я читаю в рассылках, делают мои
> глаза заметно крупнее обычного, поэтому я хотел бы дать несколько
> уместных на мой взгляд пояснений.
>
> 0. Часто можно видеть письма "я решил проблему таким образом" или
> "давайте всё сделаем вот так-то". Банально, но всё же. Уважаемые
> подписчики, когда вы так пишете, сформулируйте пожалуйста решаемую
> задачу, это заметно поможет всем.
>
> 1. Сервис ifrename и файл /etc/iftab. Замечательная вещь для
> пользователей net-scripts.
<skip />

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

В идеале было бы, если бы этой ручкой был chkconfig. Банально, но зато а) 
работает б) всем понятно. Чтобы при необходимости человек не лазал по k 
недокументированным файлам и не искал невнятные переменные.

>
> 2. udev. Я слышал, эта штука нужна для заполнения /dev при старте
> (вместо того, чтобы сделать это один раз, вот чудаки) и в некоторых

а про read-only rootfs с /dev на tmpfs ты слышал? Не, ну правда. Бывают разные 
ситуации, и Сизиф пока ещё можно использовать для сборки разных решений.

> дистрибутивах даже отключается, например, у нас. Практическим
> следствием отключения сервиса udev у меня стало игнорирование
> USB-кардридера, так что, покосившись на лишний сервис, я всё-таки
> включил udev назад. На работу моей домосетки эти эволюции влияния не
> оказали (составить такую конфигурацию нетрудно). Также меня
> заинтересовали предложения обучить udev искусственному интеллекту и

Урл... Не понимаю намёков, или не помню треда.

> игре на балалайке (помнится, предыдущим исполнителем роли Шарикова был
> hotplug). Я не знаю, кто решится тратить на это время, но я предвижу,
> каким будет результат. Давайте проектировать дистрибутив так, чтобы

Есть udev, который документированно провайдит некие ядерные события, и 
справляется вроде. Каждый, кто хочет эти события обрабатывать именно таким 
образом (а для меня, например, netlink пока оказался удобнее), устанавливает 
файлик в rules. Не вижу проблем.

> каждая компонента решала одну задачу, но хорошо. Например, загружала
> модули в ядро и дёргала за хвост соседнюю, которая из имеющейся
> заготовки выстрогает интерфейс.

"ты не мудри, ты пальцем покажи"

Если честно, вообще не понял, что ты предлагаешь сделать с udev'ом. By me, с 
ним сейчас всё в порядке - работает, и это хорошо.

>
> 3. И наконец, наш философский камень, чаша Грааля и мелафон в одном

s/мелафон/боян/ ;)

> лице. eth0. Скажите пожалуйста, имея в системе два интерфейса, зачем
> называть один из их eth0? А второй зачем называть eth1? А потом штурмом
> добиваться соответствия реального мира содержимому iftab? Я позволю
> себе ответить на этот вопрос. В этом точно нет достаточно большого
> смысла, и под вопросом, есть ли смысл маленький. Ещё раз попробую
> сформулировать уже высказанное предложение. Оставьте ядру ядерное и
> пусть оно нумерует свои свежесозданные интерфейсы eth0, eth1, eth2 ...
> eth99. Пул в 100 интерфейсов устроит всех. Если мы будем брать из этого
> пула по одному интерфейсу и называть их eth000, eth001, eth002 ...
> eth099, то мир станет немного чище и проще. Пользователь будет видеть
> привычное eth, а у ядра и конфигуратора будет место для маневров.

Да что тебе eth0 покоя не даёт? :)) Пытаешься убедить пользователей, что он не 
нужен, потому что etcnet его не умеет? :)

Ну, не умеет и баста. Это а) вроде бы документировано? б) обосновано в твоём 
случае. Всех несогласных посылай лесом^W в другие конфигураторы сети, которые 
умеют eth0, благо их предостаточно (и тех, кому нужен, и тех, кто умеет). 
Можно даже в faq вставить, если ещё не.

>
> Спасибо за внимание и надеюсь видеть следующий maintenance
> release более согласованным.

С кем? ;)

-- 
Peter V. Saveliev