В этом отношении, что именно было не так с кучей статических файлов в /dev? Очевидно, что для разработчиков недостаточно того, чтобы заново изобретать это колесо по моим подсчетам 3 раза ( devfs-> udev + HAL-> udev), и теперь, очевидно, оно также входит в программу «Великий объединенный инициал», то есть четыре раза.

Помню, когда я впервые начал использовать Linux много лет назад, я был удивлен, что, несмотря на заявления о том, что «все является файлом», его нет /dev/eth0(это позже имело смысл, поскольку это не символ или блочное устройство - хотя это «пакетное» устройство). было бы интересно ...). Учитывая это, почему программа, которая обрабатывает дерево файлов char и block device, также отвечает за сетевые устройства? Я видел смутные ссылки на «гибкость», но что это добавляет к тому, что, скажем, ifconfig (8) делает, просто просматривая /proc/net/dev? Я знаю, например, что NetworkManager не будет в сети или в OpenBSD в ближайшее время, потому что это зависит от того udev, что ни одна из команд не хочет писать; что я не делаю/devкоторые уже выставлены ядром множеством способов (и ни один из них в /dev!).

Это только из-за горячего подключения? Были ли проблемы с ядром, просто слушающим физические шины и загружающим соответствующие модули в сообщении «добавлено устройство»? Или, не дай Бог, действующий администратор делает это? Я помню, что в начале 2000-х мои серверы иногда инициализировали свои сетевые карты в неожиданном порядке, и я полагаю, что имеет смысл принять решение о присвоении имен в пользовательской среде (хотя это было не очень сложно исправить в то время), но это похоже на кувалду для таракана. (Или, может быть, эта проблема затрагивает сценарии использования, о которых я не думаю гораздо сложнее, чем стоечные серверы или ПК, которые являются моим опытом.)

Итак, чтобы сформулировать мой вопрос прямо: какие проблемы на самом деле решает udev, и как devfs, HAL и / или обычный старый файл не смогли их решить? Есть ли конкретная причина, по которой все эти разные вещи (горячее подключение, общее управление устройствами, управление сетевыми устройствами, именование устройств, приоритет драйверов и т. Д.) Должны быть одной программой?

Еще две вещи: переход Linux на корпоративные и другие крупные серверы подвергает статическую /devуязвимость. Развивающиеся технологии, как на потребительском, так и на корпоративном уровне, выставляли static / dev как шутку. [Этот ответ заполняет большую часть предыстории, не особенно то, почему devfs был заменен на udev].

Исчерпание большого и малого номера пространства

/devфайлы идентифицируются внутри ядра по их старшим и младшим номерам. Ядро на самом деле никогда не заботилось об имени (и вы могли бы, например, mv /dev/sda /dev/disk-1и оно продолжало бы работать - хотя, конечно, программы не знали бы, где его найти).

При использовании статического кода /devвам необходимо выделить старший / младший номер для каждого потенциального устройства, которое может существовать. Эти цифры должны быть уникальными во всем мире, так как они поставляются как часть дистрибутивов, а не создаются по требованию. Проблема в том, что каждое из них является 8-битным числом - диапазон от 0 до 255.

Первоначально, например, Linux начинался с 8,0 с sda, 8,1 с sda1, 8,16 с sdb и т. Д. Но люди продолжали добавлять все больше дисков к машинам, особенно когда вы рассматривали такие вещи, как оптоволоконный канал. Так что в какой-то момент старшие номера 65–71 были добавлены для большего количества дисков. Позже мажорные номера 128–135. И все же люди продолжали хотеть больше дисков ...

И появились форматы таблиц разделов, такие как GPT, поддерживающие большее количество разделов на диск. И, конечно, другие устройства перебирали пространство номеров: различные RAID-контроллеры, управление логическими томами и т. Д.

Конечный результат можно увидеть в списке устройств Linux LANANA . Если вы посмотрите на список 2.6 (единственный, который все еще там), то используется большое количество старших номеров блоков до 200 (максимум: 255). Понятно, что цифры закончились бы.

Переход на большее число было нелегким. Это меняет ядро ​​ABI. В зависимости от файловой системы, это меняет расположение на диске. Но, конечно, большинство из этих устройств не существовало ни в одной из систем, даже у того, на котором (например) заканчивались диски SCSI, вероятно, было много свободных вещей - вероятно, не требовался жесткий диск IBM XT, например.

С динамикой /dev, дистрибутив не должен отправлять номера устройств. Они больше не должны быть глобально уникальными. Они даже не должны быть уникальными среди сапог.

Названия устройств были непредсказуемыми

Раньше было действительно легко присвоить номер всему. На плате было два канала IDE; каждый канал IDE поддерживает одного главного и одного подчиненного. Вы можете назначить их в порядке каналов и в порядке «ведущий-потом-ведомый». Так hdaстановится первым каналом, мастер; hdbпервый канал, раб; hdcвторой канал, мастер; и т. д. Те были предсказуемы и стабильны. Они могут измениться, если вы добавите новый диск или удалите один, но при отсутствии смены оборудования, они были статическими.

Вы можете вставить /dev/hda1свой /etc/fstabи быть уверенным, что он останется работать, по крайней мере, при отсутствии аппаратных изменений.

IDE работал так. Ничего после этого не делает.

SATA выглядит просто: один порт, один диск. Но не так; это позволяет множители портов. И это позволяет горячую замену. Тем не менее, при отсутствии изменений в оборудовании, вы можете по-прежнему поддерживать отображение.

USB намного хуже. Это не только позволяет горячую замену, это типично. Люди постоянно подключают USB-накопители. Кроме того, устройствам может потребоваться некоторое время для проверки - и они могут фактически меняться всякий раз, когда им это нравится (например, при включении или выключении режима USB-накопителя на вашем телефоне). Firewire похож. Ни с одним из них вы не сможете придумать стабильное отображение.

Подключенные к сети диски не имеют собственного порядка портов. Единственный порядок, который использует ядро, это порядок, в котором они появились. То же самое с логическими томами.

Стремление к скорости загрузки также ухудшило ситуацию. Первоначально ядро ​​с удовольствием сидело бы без дела и ожидало довольно много времени, например, для инициализации всех USB-устройств. Чтобы полностью исследовать все шины SCSI и т. Д. Эти зонды были превращены в фоновые задачи; boot больше не будет ждать их Устройства добавляются после завершения проверки.

Таким образом, ядро ​​осталось более или менее «в любом порядке, в котором они появляются». Это означало, что многие типы устройств могут изменять порядок загрузки при каждой загрузке - то, что было при одной загрузке, /dev/sdbбыло при другой загрузке /dev/sdc. Это делает идею статичной /devшуткой.

Резюме

Когда вы принимаете комбинацию статического кода, /devстановящегося все более бессмысленным из-за непредсказуемых порядков проверки устройств и продолжая выделять статические старшие / младшие числа, ведущие к существенной работе, которая не заканчивается, становится понятно, почему разработчики Linux решили перейти на динамическое /dev.

Хороший вопрос.

В некотором смысле этот аргумент можно перевернуть: поскольку ядро ​​2.6.13 представило новую версию uevent, должно было случиться так, что devfsего придется переписать, чтобы воспользоваться преимуществами новых функций интерфейса. Таким образом, в некотором смысле, вопрос должен быть, почему изменения в ядре.

Однако, принимая это за чистую монету, на ваш вопрос ответили в этой статье Википедии :

В отличие от традиционных систем Unix, где узлы устройств в каталоге / dev были статическим набором файлов, диспетчер устройств Linux udev динамически предоставляет только узлы для устройств, фактически присутствующих в системе. Хотя devfs раньше предоставлял похожую функциональность, Грег Кроа-Хартман привел ряд причин, по которым его реализация предпочтительнее, чем devfs:

1) udev поддерживает постоянное именование устройств, которое не зависит, например, от порядка, в котором устройства подключены к системе. Настройка udev по умолчанию предоставляет постоянные имена для устройств хранения. Любой жесткий диск распознается по уникальному идентификатору файловой системы, имени диска и физическому расположению на оборудовании, к которому он подключен.

2) udev выполняется полностью в пользовательском пространстве, в отличие от пространства ядра devfs. Одним из следствий этого является то, что udev перенес политику именования из ядра и может запускать произвольные программы для составления имени устройства из свойств устройства до создания узла; там весь процесс также прерывается, и он работает с более низким приоритетом.

Я, вероятно, должен добавить, что с помощью udev исключается возможность использования a race condition, которое в основном подрывает имена устройств в devfs и hotplug. Другими словами: с devfs не было никакого способа гарантировать, что ваш самый левый порт Ethernet будет вызываться, eth0а его самый правый порт, что eth1затрудняет (в качестве чистого примера) настройку маршрутизаторов (один порт для WAN, один порт для LAN), трудно воплощать в жизнь.

Принятие схемы именования дисков, основанной на GUID, является еще одним плюсом и переводит весь процесс в пользовательское пространство еще более масштабным: вы просматривали этот сайт, чтобы увидеть, сколько людей пишут свои собственные правила udev?

В качестве простого примера преимуществ, присущих наличию udev в пользовательском пространстве, проверьте либо этот вопрос, либо этот другой вопрос , оба на этом самом сайте.