З цього питання, що саме було не так у купі статичних файлів /dev? Це, мабуть, недостатньо задовільно, щоб розробники переробили це колесо за моїм рахунком 3 рази ( devfs-> udev + HAL-> udev), і тепер, мабуть, воно також входить до Гранд Уніфікованої програми Init, так чотири рази.

Пам'ятаю, коли я вперше почав використовувати Linux років тому, дивувався, що, незважаючи на твердження, що "все є файлом", цього немає /dev/eth0(це пізніше мало сенс, оскільки це не чарівне або блокове пристрій - хоча тип "пакетного" пристрою) було б цікаво ...). Враховуючи це, чому програма, яка обробляє дерево файлів char та блокування пристроїв, також відповідає за мережеві пристрої? Я бачив розпливчасті посилання на "гнучкість", але що це додає до того, що, скажімо, ifconfig (8) робить, просто заглянувши /proc/net/dev? Я знаю, наприклад, що NetworkManager незабаром не буде в мережі Net або OpenBSD, оскільки це залежить від того udev, про що не хоче писати жодна команда; що я не роблю '/devякі вже піддаються ядром (і жоден з них не доступний /dev!).

Це тільки через гарячу підключення? Чи були проблеми з ядром просто прослуховуванням фізичної шини та завантаженням відповідних модулів на повідомлення "додано пристрій"? Або, не дай Бог, фактичний адміністратор так чинить? Я пам’ятаю ще на початку 2000-х мої сервери іноді ініціалізували свої мережеві картки у несподіваному порядку, і я вважаю, що має сенс прийняти таке іменування у користувальницькій країні (хоча тоді це було не дуже важко виправити), але це здається кувалдою для таргана. (Або, можливо, ця проблема вражає випадки, коли я не замислююся про набагато важчіші місця, ніж моторошні сервери чи ПК, які є моїм досвідом.)

Отже, викласти моє запитання однозначно: які проблеми насправді вирішує udev, і як devfs, HAL та / або звичайний старий файл не змогли їх вирішити? Чи є певна причина, що всі різні речі (гаряча підключення, загальне управління пристроєм, управління мережевими пристроями, іменування пристроїв, пріоритет драйвера тощо) - це одна програма?

Ще дві речі: переміщення Linux на корпоративні та інші великі сервери виявляло статичні /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-контролери, логічне управління гучністю тощо.

Кінцевий результат можна побачити у списку пристроїв LANANA Linux . Якщо ви подивитеся на список 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 і т. Д. Ці зонди були перетворені на основні завдання; черевик більше не буде чекати на них. Пристрої додаються по мірі завершення зондів.

Таким чином, ядро ​​було залишене в більшій чи меншій мірі, "в якому б порядку вони не з'являлися". Це означало, що багато типів пристроїв можуть і змінювали порядок кожного завантаження - те, що було на одному завантаженні, /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 в просторі користувачів, перевірте або це, або це інше питання , як на цьому самому сайті.