.
, DevFS . - , devfs " " Σ devtmpfs?
On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote:
Здравствуйте.
Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
заменён на devtmpfs?
https://lkml.org/
2002-2020, , - ݣ 90-. , , , , devfs, , ޣ : https://www.google.com/search?q=devfs+site:lkml.org
- / ?
30.07.2022 15:04, :
On Sat, Jul 30, 2022 at 02:14:31PM +0300, ԣ . wrote:
.
, DevFS . - , devfs " " Σ devtmpfs?
https://lkml.org/
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
30.07.2022 15:04, Иван Лох пишет:
On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote:
Здравствуйте.
Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
заменён на devtmpfs?
https://lkml.org/
Уф... давно дело было, конечно, но.....
Во-первых, в вашем повествовании пропущена целая эпоха под названием udev.
Во-вторых, на сколько я помню, всю эту кашу заварили по сути из-за hotplug,
когда ноды стали появляться и исчезать динамически. Devfs была интересной
штукой, но в зависимости от последовательности вставления девайсов или в
зависимости от енумератора шин при загрузке, девайсы не имели предсказуемых
имен.
По-моему, вот тут всё описано более менее четко:
https://web.archive.org/web/20110411233322/http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
сб, 30 июл. 2022 г. в 14:24, Артём Н. <artiom14@yandex.ru>:
Здравствуйте.
Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
заменён на devtmpfs?
Уверен, что тут есть те, кто и первой активно пользовались, и в любом
случае, буду вам благодарен за любые замечания по тексту:
```
Существовало несколько вариантов поддержки устройств в Unix-подобных ОС
и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через
вызов makedev() создаёт большой набор файлов устройств, не проверяя то,
есть эти устройства реально или нет. Если пользователь обратится к
несуществующему устройству, система просто выдаст ошибку. Тогда /dev был
лишь подкаталогом корневой файловой системы. И созданные файлы устройств
существовали там всегда, а MAKEDEV запускался при необходимости.
Затем разработчики Linux добавили в ядро поддержку devfs (не той,
которая используется сейчас). С ней возникли проблемы. Например,
пользовательские скрипты при загрузке должны были ожидать заполнения
иерархии и как-то синхронизироваться, необходимость явных вызовов изо
всех драйверов и т.д. Проблемы решались с переменным успехом, но система
не прижилась.
Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал
устройства, о которых ядро предоставляло информацию (т.е. которые
реально существуют). У такого подхода были недостатки: излишние
обращения к ядру, по сути двойное перечисление устройств, понижающие
скорость загрузки, необходимость поддержки в пространстве пользователя.
Всё это усложняло использование системы во встраиваемых устройствах.
Современный Linux монтирует в /dev файловую систему DevTmpFS, которая
сразу отображает все перечисленные ядром устройства, и поддерживающий
различные правила и события демон udev, при необходимости,
обеспечивающий её динамическую конфигурацию из пространства пользователя.
```
сб, 30 июл. 2022 г. в 16:39, Артём Н. <artiom14@yandex.ru>:
Вот, отлично. То, что надо.
А по udev в чём проблема? Он же появился самый последний?
Ну то, в каком виде он сейчас - это не то, как была на рубеже отказа от
devfs. Если я правильно помню, то тогда никакого devtmpfs не было. Была
просто tmpfs, ноды в котором создавал udev. И ещё это работало с паре с вот
этим делом https://linux.die.net/man/8/hotplug
И я в конце его упомянул (а сейчас и так все знают, что это).
А сейчас вроде читал, что ещё что-то хотят внедрить, так как Android не
хочет в себя udev тянуть, а без него там тяжко. Хотят придумать что-то, что
устроит всех.
Понял, допишу. Спасибо.
Не хватало ещё очередного демона взамен udev, интегрированного в systemd.
31.07.2022 02:17, Артём Н. пишет:
Понял, допишу. Спасибо.
Не хватало ещё очередного демона взамен udev, интегрированного в systemd.
Спасибо, повеселило. Ничего, что udev самым бессовестным образом лежит
_внутри_ репозитория systemd?
Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательныйпока
элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать
udev наплодит там нужные ноды.
Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было
предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не
составит никакого труда.
То есть да - во многом идеи, которые вложены в обе
подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе
доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили
изучить?
От себя добавлю: интерфейс devfs, если я правильно помню,подразумевал то,
что через /proc задавался путь программы, которая будет запускатьсяядром,
если требуется какое-то действие. Это называлось usermode helper. Вслучае
с udev программу запускает юзер один раз, и она общается с ядром по
интерфейсу а-ля шина.
...
без необходимости писать и самое главное поддерживать в ядре и вдрайверах кучу кода, отвечающего за devfs.
вс, 31 июл. 2022 г. в 14:27, Артём Н. <artiom14@yandex.ru>:
В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
/dev, просто ради любопыства, там будут устройства, выставленные ядром.
Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный
элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока
udev наплодит там нужные ноды.
> Кажется, нельзя было например попросить систему всегда давать
определенное
> имя сетевой карте с определенным мак-адресом
> (сейчас через udev это легко делается)
Но это же делает набор правил уже *после* того, как устройство было
выставлено драйвером.
Или я что-то неправильно понимаю?
> Фишка udev еще в том, что пользователь настраивает правила, имея
> возможность давать устройствам имена, >> > запускать скрипты при их появлении, запрещать какие-то устройства итд.
Я так понимаю, что devfsd, который был до него, этим тоже занимался?
запускать скрипты при их появлении, запрещать какие-то устройства итд.
Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было
предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не
составит никакого труда. То есть да - во многом идеи, которые вложены в обе
подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе
доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили
изучить?
От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то,
что через /proc задавался путь программы, которая будет запускаться ядром,
если требуется какое-то действие. Это называлось usermode helper. В случае
с udev программу запускает юзер один раз, и она общается с ядром по
интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать
параметры, исходя из которых юзер может кастомизировать
присваиваемые названия нодам и устройствам, а также задавать права доступа
к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так
далее. Наверное, было можно заморочиться и сделать подобное с devfs, но
решили отказаться потому что придумали как сделать это всё более чисто и
без необходимости писать и самое главное поддерживать в ядре и в драйверах
кучу кода, отвечающего за devfs.
Видимо это и есть ответ на ваш вопрос:)
Но это же делает набор правил уже *после* того, как устройство было
выставлено драйвером.
Или я что-то неправильно понимаю?
Не совсем 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
Видимо это и есть ответ на ваш вопрос:)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:32:35 |
| Calls: | 6,706 |
| Calls today: | 6 |
| Files: | 12,235 |
| Messages: | 5,350,197 |