=?UTF-8?B?RGV2RlMg0Lgg0L/RgNC+0YfQuNC1?=
From
=?UTF-8?B?0JDRgNGC0ZHQvCDQnS4=?=@21:1/5 to
All on Sat Jul 30 13:30:01 2022
Здравствуйте.
Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
заменён на devtmpfs?
Уверен, что тут есть те, кто и первой активно пользовались, и в любом
случае, буду вам благодарен за любые замечания по тексту:
```
Существовало несколько вариантов поддержки устройств в Unix-подобных ОС
и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через
вызов makedev() создаёт большой набор файлов устройств, не проверяя то,
есть эти устройства реально или нет. Если пользователь обратится к
несуществующему устройству, система просто выдаст ошибку. Тогда /dev был
лишь подкаталогом корневой файловой системы. И созданные файлы устройств
существовали там всегда, а MAKEDEV запускался при необходимости.
Затем разработчики Linux добавили в ядро поддержку devfs (не той,
которая используется сейчас). С ней возникли проблемы. Например,
пользовательские скрипты при загрузке должны были ожидать заполнения
иерархии и как-то синхронизироваться, необходимость явных вызовов изо
всех драйверов и т.д. Проблемы решались с переменным успехом, но система
не прижилась.
Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал
устройства, о которых ядро предоставляло информацию (т.е. которые
реально существуют). У такого подхода были недостатки: излишние
обращения к ядру, по сути двойное перечисление устройств, понижающие
скорость загрузки, необходимость поддержки в пространстве пользователя.
Всё это усложняло использование системы во встраиваемых устройствах.
Современный Linux монтирует в /dev файловую систему DevTmpFS, которая
сразу отображает все перечисленные ядром устройства, и поддерживающий
различные правила и события демон udev, при необходимости,
обеспечивающий её динамическую конфигурацию из пространства пользователя.
```
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)