Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DevFS и прочие

0 views
Skip to first unread message

Артём Н.

unread,
Jul 30, 2022, 7:30:03 AM7/30/22
to
Здравствуйте.


Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
заменён на devtmpfs?

Уверен, что тут есть те, кто и первой активно пользовались, и в любом
случае, буду вам благодарен за любые замечания по тексту:

```
Существовало несколько вариантов поддержки устройств в Unix-подобных ОС
и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через
вызов makedev() создаёт большой набор файлов устройств, не проверяя то,
есть эти устройства реально или нет. Если пользователь обратится к
несуществующему устройству, система просто выдаст ошибку. Тогда /dev был
лишь подкаталогом корневой файловой системы. И созданные файлы устройств
существовали там всегда, а MAKEDEV запускался при необходимости.

Затем разработчики Linux добавили в ядро поддержку devfs (не той,
которая используется сейчас). С ней возникли проблемы. Например,
пользовательские скрипты при загрузке должны были ожидать заполнения
иерархии и как-то синхронизироваться, необходимость явных вызовов изо
всех драйверов и т.д. Проблемы решались с переменным успехом, но система
не прижилась.

Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал
устройства, о которых ядро предоставляло информацию (т.е. которые
реально существуют). У такого подхода были недостатки: излишние
обращения к ядру, по сути двойное перечисление устройств, понижающие
скорость загрузки, необходимость поддержки в пространстве пользователя.
Всё это усложняло использование системы во встраиваемых устройствах.

Современный Linux монтирует в /dev файловую систему DevTmpFS, которая
сразу отображает все перечисленные ядром устройства, и поддерживающий
различные правила и события демон udev, при необходимости,
обеспечивающий её динамическую конфигурацию из пространства пользователя.
```

Иван Лох

unread,
Jul 30, 2022, 8:10:03 AM7/30/22
to
On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote:
> Здравствуйте.
>
>
> Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
> Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
> заменён на devtmpfs?

https://lkml.org/

Артём Н.

unread,
Jul 30, 2022, 9:10:05 AM7/30/22
to
Так 2002-2020, а некоторые решения, о которых я спрашиваю - это ещё 90-е.
Кроме того, искать в тысячах сообщений именно то, что нужно, далеко не
так просто, ну и та информация по devfs, которая там есть, мало о чём
говорит: https://www.google.com/search?q=devfs+site:lkml.org

Возможно кто-то помнит или может кинуть ссылку на конкретную
документацию/обсуждение по вопросу?


30.07.2022 15:04, Иван Лох пишет:

Иван Лох

unread,
Jul 30, 2022, 9:20:03 AM7/30/22
to
On Sat, Jul 30, 2022 at 03:57:35PM +0300, Артём Н. wrote:
> Так 2002-2020, а некоторые решения, о которых я спрашиваю - это ещё 90-е.
> Кроме того, искать в тысячах сообщений именно то, что нужно, далеко не так
> просто, ну и та информация по devfs, которая там есть, мало о чём говорит:
> https://www.google.com/search?q=devfs+site:lkml.org
>
> Возможно кто-то помнит или может кинуть ссылку на конкретную
> документацию/обсуждение по вопросу?

Дискуссия, которая привела к появлению udev была именно там.
О devfs совсем просто написано здесь
http://rus-linux.net/MyLDP/file-sys/holm/l-fs4_ru.html

Maksim Dmitrichenko

unread,
Jul 30, 2022, 9:20:03 AM7/30/22
to
Уф... давно дело было, конечно, но.....

Во-первых, в вашем повествовании пропущена целая эпоха под названием udev.

Во-вторых, на сколько я помню, всю эту кашу заварили по сути из-за hotplug, когда ноды стали появляться и исчезать динамически. Devfs была интересной штукой, но в зависимости от последовательности вставления девайсов или в зависимости от енумератора шин при загрузке, девайсы не имели предсказуемых имен.

По-моему, вот тут всё описано более менее четко: https://web.archive.org/web/20110411233322/http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

сб, 30 июл. 2022 г. в 14:24, Артём Н. <arti...@yandex.ru>:


--
With best regards
  Maksim Dmitrichenko

Артём Н.

unread,
Jul 30, 2022, 9:30:03 AM7/30/22
to
Ok, буду искать дискуссию. А описание я видел это. Там "красота devfs",
но система почему-то загнулась...


30.07.2022 16:13, Иван Лох пишет:

Артём Н.

unread,
Jul 30, 2022, 9:40:03 AM7/30/22
to
Вот, отлично. То, что надо.
А по udev в чём проблема? Он же появился самый последний?
И я в конце его упомянул (а сейчас и так все знают, что это).


30.07.2022 16:18, Maksim Dmitrichenko пишет:

Maksim Dmitrichenko

unread,
Jul 30, 2022, 1:10:03 PM7/30/22
to

сб, 30 июл. 2022 г. в 16:39, Артём Н. <arti...@yandex.ru>:
Вот, отлично. То, что надо.
А по udev в чём проблема? Он же появился самый последний?

Ну то, в каком виде он сейчас - это не то, как была на рубеже отказа от devfs. Если я правильно помню, то тогда никакого devtmpfs не было. Была просто tmpfs, ноды в котором создавал udev. И ещё это работало с паре с вот этим делом https://linux.die.net/man/8/hotplug 
 
И я в конце его упомянул (а сейчас и так все знают, что это).

А сейчас вроде читал, что ещё что-то хотят внедрить, так как Android не хочет в себя udev тянуть, а без него там тяжко. Хотят придумать что-то, что устроит всех.

Артём Н.

unread,
Jul 30, 2022, 6:30:03 PM7/30/22
to
Понял, допишу. Спасибо.
Не хватало ещё очередного демона взамен udev, интегрированного в systemd.


30.07.2022 20:02, Maksim Dmitrichenko пишет:

Alexander Galanin

unread,
Jul 31, 2022, 2:50:03 AM7/31/22
to
31.07.2022 02:17, Артём Н. пишет:
> Понял, допишу. Спасибо.
> Не хватало ещё очередного демона взамен udev, интегрированного в systemd.

Спасибо, повеселило. Ничего, что udev самым бессовестным образом лежит
_внутри_ репозитория systemd?

--
Alexander Galanin

IL Ka

unread,
Jul 31, 2022, 5:00:05 AM7/31/22
to
Добрый день,
 

Затем разработчики Linux добавили в ядро поддержку devfs (не той,
которая используется сейчас). С ней возникли проблемы. Например,
пользовательские скрипты при загрузке должны были ожидать заполнения
иерархии и как-то синхронизироваться, необходимость явных вызовов изо
всех драйверов и т.д. Проблемы решались с переменным успехом, но система
не прижилась.

Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял.
Кажется, нельзя было например попросить систему всегда давать определенное имя сетевой карте с определенным мак-адресом
(сейчас через udev это легко делается)

 

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

Фишка udev еще в том, что пользователь настраивает правила, имея возможность давать устройствам имена,
запускать скрипты при их появлении, запрещать какие-то устройства итд.


 

Артём Н.

unread,
Jul 31, 2022, 7:30:03 AM7/31/22
to
Ну, а я про что?
Андроид же, как я понял, хочет наоборот: сделать отдельный велосипед
("вернуть всё взад").
Не вижу тут ничего весёлого.


31.07.2022 09:41, Alexander Galanin пишет:

Артём Н.

unread,
Jul 31, 2022, 7:30:03 AM7/31/22
to
Здравствуйте.


> Тут наверное стоило бы рассказать, что в Devfs файл устройства
создавал драйвер, пользователь на это никак не влиял.

В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
/dev, просто ради любопыства, там будут устройства, выставленные ядром.


> Кажется, нельзя было например попросить систему всегда давать
определенное
> имя сетевой карте с определенным мак-адресом
> (сейчас через udev это легко делается)

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


> Фишка udev еще в том, что пользователь настраивает правила, имея
> возможность давать устройствам имена,
> запускать скрипты при их появлении, запрещать какие-то устройства итд.

Я так понимаю, что devfsd, который был до него, этим тоже занимался?


31.07.2022 11:57, IL Ka пишет:

Maksim Dmitrichenko

unread,
Jul 31, 2022, 7:50:04 AM7/31/22
to
вс, 31 июл. 2022 г. в 14:27, Артём Н. <arti...@yandex.ru>:

В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
/dev, просто ради любопыства, там будут устройства, выставленные ядром.

Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды.
 
 > Кажется, нельзя было например попросить систему всегда давать
определенное
 > имя сетевой карте с определенным мак-адресом
 > (сейчас через udev это легко делается)

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


 > Фишка udev еще в том, что пользователь настраивает правила, имея
 > возможность давать устройствам имена,
 > запускать скрипты при их появлении, запрещать какие-то устройства итд.

Я так понимаю, что devfsd, который был до него, этим тоже занимался?
> запускать скрипты при их появлении, запрещать какие-то устройства итд.

Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не составит никакого труда. То есть да - во многом идеи, которые вложены в обе подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили изучить?

От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, что через /proc задавался путь программы, которая будет запускаться ядром, если требуется какое-то действие. Это называлось usermode helper. В случае с udev программу запускает юзер один раз, и она общается с ядром по интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать параметры, исходя из которых юзер может кастомизировать присваиваемые названия нодам и устройствам, а также задавать права доступа к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так далее. Наверное, было можно заморочиться и сделать подобное с devfs, но решили отказаться потому что придумали как сделать это всё более чисто и без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs.

Артём Н.

unread,
Jul 31, 2022, 11:10:04 AM7/31/22
to
> Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный
> элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать
пока
> udev наплодит там нужные ноды.

Ну, т.е. сначала ноды экспортируются из ядра, затем применяются udev
правила (операция переименования быстрая), после чего, по inotify
(другой вызов, но я не помню) на sysfs делаются корректировки по событиям?


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

Да, я читал (и там, скорее "ну опять devfs?"). Они говорят, что нет,
таких проблем, как было, не будет.
А каких, там не упомянуто, видимо "и так все знают".


> То есть да - во многом идеи, которые вложены в обе
> подсистемы, общие. Но я вам кинул ссылку,
> где Грэг сравнивает вполне себе
> доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили
> изучить?

Ну, вообще-то у меня далеко не один источник и не единственная задача.

Но почему вы считаете, что я "не осилил изучить"?
Я прочитал и уже дописал к себе причины.

В источнике написано примерно то, о чём вы и сказали: "персистентность
устройств" - главное преимущество.
Это разве в чём-то противоречит тому, что devfsd занимался примерно тем
же самым, что и udev, да и вообще, разве там есть хоть что-то про devfsd
(я обращаю внимание: про демон, а не про ФС)?


> От себя добавлю: интерфейс devfs, если я правильно помню,
подразумевал то,
> что через /proc задавался путь программы, которая будет запускаться
ядром,
> если требуется какое-то действие. Это называлось usermode helper. В
случае
> с udev программу запускает юзер один раз, и она общается с ядром по
> интерфейсу а-ля шина.
> ...

Т.е., как и написал выше: суть та же. Но более прозрачно и эффективно
сделано, более естественно. И гораздо более гибко настраивается.

Кстати, про user-helper я с трудом но что-то припомнил, тоже допишу.
Если я помню верно, хэлпер давал сигнал демону.
Т.е. это были не скрипты, которые применяли какие-то правила, а именно
запускалась программа (возможно это был симлинк на бинарник демона),
которая давала сигнал демону?


> без необходимости писать и самое главное поддерживать в ядре и в
драйверах кучу кода, отвечающего за devfs.

Допишу в "плюсы".


31.07.2022 14:48, Maksim Dmitrichenko пишет:

Артём Н.

unread,
Jul 31, 2022, 11:40:02 AM7/31/22
to
Хотя, в целом, для врезки информации достаточно.


31.07.2022 14:48, Maksim Dmitrichenko пишет:
> вс, 31 июл. 2022 г. в 14:27, Артём Н. <arti...@yandex.ru>:
>
>>
>> В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
>> /dev, просто ради любопыства, там будут устройства, выставленные ядром.
>>
>
> Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный
> элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока
> udev наплодит там нужные ноды.
>
> ...

Артём Н.

unread,
Jul 31, 2022, 11:40:03 AM7/31/22
to
Ну, или точнее, про демон, который идёт вместе с devfs, там есть одно
упоминание, но мне не вполне ясно, это про devfsd (который пришёл на
замену devfs вместе с её демоном, как я понял) или нет?

Т.е., udev к devtmpfs не имеет прямого отношения: это просто независимо
работающие вещи, тут всё ясно.

А что пришло на замену devfs не вполне ясно: то ли был параллельно
какой-то devfsd (именно независимый от devfs "пользовательский" демон),
то ли после, то ли сразу был udev...

IL Ka

unread,
Jul 31, 2022, 1:10:04 PM7/31/22
to

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

Не совсем imho: В devfs файлы устройств появлялись от вызова драйвером devfs_register.
devfsd мог по ним сделать символические ссылки, но сами файлы он не трогал.
В случае же udev, драйвер создает специальную структуру (она видна в /sys), и посылает uevent (через NETLINK), и udev уже создает нужную запись.

Кмк, дело было так:

До 2.4 все устройства создавались mkdev и драйвер привязывался к major номеру.
Ненужные файлы забивали /dev, путали пользователя, имели проблемы с безопасностью (решение о пермишенах принимал автор скрипта MAKEDEV) а еще и major номера начали кончаться (их было-то всего 255).

В 2.4 проблему решили devfs, позволив драйверу самому создавать устройство через devfs_register.
Подробнее погуглите главу "The Device Filesystem" второго (не третьего!) издания Linux Driver Development.

Стало лучше: в dev не стало несуществующих устройств и драйвер смог выбирать пермишены на файл.
Однако осталась проблемы, наример пользователь всё еще не мог выбирать как назвать устройство оперируя его идентификатором.
У каждой шины (PCI, USB) у устройства есть уникальные ID, и хотелось бы привязывать имена к ним.
Кроме того, все существующие имена приходилось хранить в памяти ядра (невыгружаемой). Появилось желание вынести это в userspace.

Всё это привело к вот такому (там много жалоб на devfs):
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf

В 2.6 сделали sys, куда драйверы стали репортовать свои устройства, затем посылать uevent, который забирал udev, и на основе рулов создавал нужное устройство,
а еще он по D-Bus мог сообщить об этом вашему DE, чтобы тот нарисовал красивый попап.

Почитать можно тут:
https://linux-kernel-labs.github.io/refs/heads/master/labs/device_model.html#sysfs

Часть людей была против, вот тут их переубеждают:  https://lwn.net/Articles/65197/

Затем udev смерджили с systemd:)

Но тут оказалось, что udev не нравится емебдщикам и не подходит для всяких rescue mode, потому что требует нехилый userspace udev.

Тогда был создан devtmpfs (тут подробно написано)
https://lwn.net/Articles/330985/

Он просто брал имена (те, что драйверы репортуют в sys)и создавал для них устройства. Файловая система была создана на основе tmpfs, так что она была намного проще, и позволяла udevу работать поверх нее

Естественно, все тут же сказали "мы опять изобрели devfs!"
https://lwn.net/Articles/331818/

Но утверждается, что:
* devtmpfs проще (сделана на основе tmpfs)
* совместима с udev 

Видимо это и есть ответ на ваш вопрос:)

Артём Н.

unread,
Jul 31, 2022, 1:50:02 PM7/31/22
to
Спасибо.


> Видимо это и есть ответ на ваш вопрос:)

Похоже, что да, и ответ полный: написано подробнее и точнее, чем мой текст.
Мне остаётся это только в "художественном стиле" переписать, и всё.


31.07.2022 20:03, IL Ka пишет:
0 new messages