Традиционная реализация Linux предоставляет пользователю абстрактный каталог устройств, называемый /dev. Внутри этого каталога находятся device nodes, специальные файлы, символизирующие устройства внутри системы. Например, /dev/hda символизирует первое IDE устройство в вашей системе. Файлы устройств позволяют создавать программы, которые взаимодействуют с устройствами так, как если бы устройства были обычными файлами, вместо использования специальных API.

Файлы устройств подразделяются на две группы, называемые character devices (символьные устройства) и block devices (блочные устройства). Первая группа содержит устройства, для котрых отсутствует буферизация чтения/записи. Вторая группа, естественно, содержит устройства, для которых чтение/запись буферизируется. Из обоих типов устройств может быть прочитан за раз один символ или блок. Поэтому такой способ присваивания имён может сбивать с толку и на самом деле неправилен.

Если посмотреть на конкретное устройство, можно обнаружить что-то, похожее на это:

# ls -l /dev/hda
brw-rw----    1 root     disk       3,   0 Jul  5  2000 /dev/hda

В предыдущем примере мы увидели, что /dev/hda — это блочное устройство. Однако важнее то, что ему присвоено два специальных номера 3, 0. Эта пара называется major-minor. Она используется ядром, чтобы соотнести файл устройства и реальное устройство. major (старший) относится к типу устройства, minor (младший) к конкретному устройству. Выглядит запутано, не правда ли?

Ещё два примера — /dev/hda4 и /dev/tty5. Первое устройство соответствует четвёртому разделу на первом IDE-устройстве. Его пара major-minor 3, 4. Другими словами, minor соответствует разделу, тогда как major соответствует устройству. Во втором примере пара major-minor — 4, 5. В этом случае первое число соответствует драйверу терминала, тогда как второе соответствует номеру терминала (в данном случае пятый терминал).

Если вы заглядывали в папку /dev, вы обнаружили, что там перечислены не только все ваши устройства, но и все возможные устройства, которые только могут быть. Другими словами, у вас есть файлы устройств для устройств, которых у вас нет. Управление такой кучей устройств по крайней мере можно назвать громоздким. Представьте, что надо поменять права на все устройства, реально существующие в вашей системе, оставив остальные без изменений.

Затем вы добавили новое оборудование в вашу систему, для него может не оказаться уже существующего файла. Продвинутые пользователи знают, что эта задача может быть выполнена с помощью команды ./MAKEDEV внутри директории /dev, но разве вы сразу знаете, что за устройство вам придётся создать?

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

Как вы могли себе представить, kernel hackers нашли достаточно решений для вышеперечисленных проблем. Однако многие из этих решений имеют собственные проблемы описанные в http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why. Мы не будем обсуждать эти варианты, а сконцентрируемся на одном способе, который был реализован в официальной версии исходников ядра:

devfs решает все перечисленные проблемы. Она просто предоставляет пользователю доступ к существующим устройствам, добавляет новые device nodes (файлы устройств), когда найдены новые устройства, и делает возможным монтировать корневую файловую систему в режиме read only (только чтение). А также решает многие проблемы, которые мы раньше не обсуждали, потому что они не так интересны для пользователей...

Как пример, с devfs вам не надо беспокоится о паре major/minor. Она продолжат поддерживаться (для обратной совместимости), но в ней нет необходимости. Это позволяет Linux поддерживать ещё больше устройств, так как больше нет ограничений (числа всегда имеют границы :)

Однако у devfs есть свои проблемы, не столь очевидные для пользователей, но достаточно серьезные, чтобы разработчики ядра пометили ее как obsolete (устаревшее), порекомендовав использовать udev, которая также поддерживается Gentoo.

Чтобы узнать, почему devfs считается устаревшей, читайте udev FAQ и udev versus devfs document.