Re: DevFS и прочие

Вот, отлично. То, что надо.
А по udev в чём проблема? Он же появился самый последний?
И я в конце его упомянул (а сейчас и так все знают, что это).


30.07.2022 16:18, Maksim Dmitrichenko пишет:
> Уф... давно дело было, конечно, но.....
> 
> Во-первых, в вашем повествовании пропущена целая эпоха под названием udev.
> 
> Во-вторых, на сколько я помню, всю эту кашу заварили по сути из-за hotplug,
> когда ноды стали появляться и исчезать динамически. Devfs была интересной
> штукой, но в зависимости от последовательности вставления девайсов или в
> зависимости от енумератора шин при загрузке, девайсы не имели предсказуемых
> имен.
> 
> По-моему, вот тут всё описано более менее четко:
> https://web.archive.org/web/20110411233322/http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
> 
> сб, 30 июл. 2022 г. в 14:24, Артём Н. <[email protected]>:
> 
>> Здравствуйте.
>>
>>
>> Пишу врезку для главы книги, и нужно краткую историю DevFS привести.
>> Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был
>> заменён на devtmpfs?
>>
>> Уверен, что тут есть те, кто и первой активно пользовались, и в любом
>> случае, буду вам благодарен за любые замечания по тексту:
>>
>> ```
>> Существовало несколько вариантов поддержки устройств в Unix-подобных ОС
>> и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через
>> вызов makedev() создаёт большой набор файлов устройств, не проверяя то,
>> есть эти устройства реально или нет. Если пользователь обратится к
>> несуществующему устройству, система просто выдаст ошибку. Тогда /dev был
>> лишь подкаталогом корневой файловой системы. И созданные файлы устройств
>> существовали там всегда, а MAKEDEV запускался при необходимости.
>>
>> Затем разработчики Linux добавили в ядро поддержку devfs (не той,
>> которая используется сейчас). С ней возникли проблемы. Например,
>> пользовательские скрипты при загрузке должны были ожидать заполнения
>> иерархии и как-то синхронизироваться, необходимость явных вызовов изо
>> всех драйверов и т.д. Проблемы решались с переменным успехом, но система
>> не прижилась.
>>
>> Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал
>> устройства, о которых ядро предоставляло информацию (т.е. которые
>> реально существуют). У такого подхода были недостатки: излишние
>> обращения к ядру, по сути двойное перечисление устройств, понижающие
>> скорость загрузки, необходимость поддержки в пространстве пользователя.
>> Всё это усложняло использование системы во встраиваемых устройствах.
>>
>> Современный Linux монтирует в /dev файловую систему DevTmpFS, которая
>> сразу отображает все перечисленные ядром устройства, и поддерживающий
>> различные правила и события демон udev, при необходимости,
>> обеспечивающий её динамическую конфигурацию из пространства пользователя.
>> ```
>>
>>
>