Здравствуйте.
> Тут наверное стоило бы рассказать, что в Devfs файл устройства
создавал драйвер, пользователь на это никак не влиял.
В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
/dev, просто ради любопыства, там будут устройства, выставленные ядром.
> Кажется, нельзя было например попросить систему всегда давать
определенное
> имя сетевой карте с определенным мак-адресом
> (сейчас через udev это легко делается)
Но это же делает набор правил уже *после* того, как устройство было
выставлено драйвером.
Или я что-то неправильно понимаю?
> Фишка udev еще в том, что пользователь настраивает правила, имея
> возможность давать устройствам имена,
> запускать скрипты при их появлении, запрещать какие-то устройства итд.
Я так понимаю, что devfsd, который был до него, этим тоже занимался?
31.07.2022 11:57, IL Ka пишет:
Добрый день,
Затем разработчики Linux добавили в ядро поддержку devfs (не той,
которая используется сейчас). С ней возникли проблемы. Например,
пользовательские скрипты при загрузке должны были ожидать заполнения
иерархии и как-то синхронизироваться, необходимость явных вызовов изо
всех драйверов и т.д. Проблемы решались с переменным успехом, но система
не прижилась.
Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал
драйвер, пользователь на это никак не влиял.
Кажется, нельзя было например попросить систему всегда давать определенное
имя сетевой карте с определенным мак-адресом
(сейчас через udev это легко делается)
Современный Linux монтирует в /dev файловую систему DevTmpFS, которая
сразу отображает все перечисленные ядром устройства, и поддерживающий
различные правила и события демон udev, при необходимости,
обеспечивающий её динамическую конфигурацию из пространства пользователя.
Фишка udev еще в том, что пользователь настраивает правила, имея
возможность давать устройствам имена,
запускать скрипты при их появлении, запрещать какие-то устройства итд.