Re: DevFS и прочие
Понял, допишу. Спасибо. Не хватало ещё очередного демона взамен udev, интегрированного в systemd. 30.07.2022 20:02, Maksim Dmitrichenko пишет: сб, 30 июл. 2022 г. в 16:39, Артём Н. : Вот, отлично. То, что надо. А по udev в чём проблема? Он же появился самый последний? Ну то, в каком виде он сейчас - это не то, как была на рубеже отказа от devfs. Если я правильно помню, то тогда никакого devtmpfs не было. Была просто tmpfs, ноды в котором создавал udev. И ещё это работало с паре с вот этим делом https://linux.die.net/man/8/hotplug И я в конце его упомянул (а сейчас и так все знают, что это). А сейчас вроде читал, что ещё что-то хотят внедрить, так как Android не хочет в себя udev тянуть, а без него там тяжко. Хотят придумать что-то, что устроит всех.
Re: DevFS и прочие
сб, 30 июл. 2022 г. в 16:39, Артём Н. : > Вот, отлично. То, что надо. > А по udev в чём проблема? Он же появился самый последний? > Ну то, в каком виде он сейчас - это не то, как была на рубеже отказа от devfs. Если я правильно помню, то тогда никакого devtmpfs не было. Была просто tmpfs, ноды в котором создавал udev. И ещё это работало с паре с вот этим делом https://linux.die.net/man/8/hotplug > И я в конце его упомянул (а сейчас и так все знают, что это). > А сейчас вроде читал, что ещё что-то хотят внедрить, так как Android не хочет в себя udev тянуть, а без него там тяжко. Хотят придумать что-то, что устроит всех. -- With best regards Maksim Dmitrichenko
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, Артём Н. : Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? Уверен, что тут есть те, кто и первой активно пользовались, и в любом случае, буду вам благодарен за любые замечания по тексту: ``` Существовало несколько вариантов поддержки устройств в Unix-подобных ОС и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через вызов makedev() создаёт большой набор файлов устройств, не проверяя то, есть эти устройства реально или нет. Если пользователь обратится к несуществующему устройству, система просто выдаст ошибку. Тогда /dev был лишь подкаталогом корневой файловой системы. И созданные файлы устройств существовали там всегда, а MAKEDEV запускался при необходимости. Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал устройства, о которых ядро предоставляло информацию (т.е. которые реально существуют). У такого подхода были недостатки: излишние обращения к ядру, по сути двойное перечисление устройств, понижающие скорость загрузки, необходимость поддержки в пространстве пользователя. Всё это усложняло использование системы во встраиваемых устройствах. Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. ```
Re: DevFS и прочие
Ok, буду искать дискуссию. А описание я видел это. Там "красота devfs", но система почему-то загнулась... 30.07.2022 16:13, Иван Лох пишет: 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/
Re: DevFS и прочие
Уф... давно дело было, конечно, но. Во-первых, в вашем повествовании пропущена целая эпоха под названием udev. Во-вторых, на сколько я помню, всю эту кашу заварили по сути из-за hotplug, когда ноды стали появляться и исчезать динамически. Devfs была интересной штукой, но в зависимости от последовательности вставления девайсов или в зависимости от енумератора шин при загрузке, девайсы не имели предсказуемых имен. По-моему, вот тут всё описано более менее четко: https://web.archive.org/web/20110411233322/http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs сб, 30 июл. 2022 г. в 14:24, Артём Н. : > Здравствуйте. > > > Пишу врезку для главы книги, и нужно краткую историю DevFS привести. > Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был > заменён на devtmpfs? > > Уверен, что тут есть те, кто и первой активно пользовались, и в любом > случае, буду вам благодарен за любые замечания по тексту: > > ``` > Существовало несколько вариантов поддержки устройств в Unix-подобных ОС > и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через > вызов makedev() создаёт большой набор файлов устройств, не проверяя то, > есть эти устройства реально или нет. Если пользователь обратится к > несуществующему устройству, система просто выдаст ошибку. Тогда /dev был > лишь подкаталогом корневой файловой системы. И созданные файлы устройств > существовали там всегда, а MAKEDEV запускался при необходимости. > > Затем разработчики Linux добавили в ядро поддержку devfs (не той, > которая используется сейчас). С ней возникли проблемы. Например, > пользовательские скрипты при загрузке должны были ожидать заполнения > иерархии и как-то синхронизироваться, необходимость явных вызовов изо > всех драйверов и т.д. Проблемы решались с переменным успехом, но система > не прижилась. > > Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал > устройства, о которых ядро предоставляло информацию (т.е. которые > реально существуют). У такого подхода были недостатки: излишние > обращения к ядру, по сути двойное перечисление устройств, понижающие > скорость загрузки, необходимость поддержки в пространстве пользователя. > Всё это усложняло использование системы во встраиваемых устройствах. > > Современный Linux монтирует в /dev файловую систему DevTmpFS, которая > сразу отображает все перечисленные ядром устройства, и поддерживающий > различные правила и события демон udev, при необходимости, > обеспечивающий её динамическую конфигурацию из пространства пользователя. > ``` > > -- With best regards Maksim Dmitrichenko
Re: DevFS и прочие
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/ > > >
Re: DevFS и прочие
Так 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/
Re: DevFS и прочие
On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote: > Здравствуйте. > > > Пишу врезку для главы книги, и нужно краткую историю DevFS привести. > Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был > заменён на devtmpfs? https://lkml.org/
DevFS и прочие
Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? Уверен, что тут есть те, кто и первой активно пользовались, и в любом случае, буду вам благодарен за любые замечания по тексту: ``` Существовало несколько вариантов поддержки устройств в Unix-подобных ОС и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через вызов makedev() создаёт большой набор файлов устройств, не проверяя то, есть эти устройства реально или нет. Если пользователь обратится к несуществующему устройству, система просто выдаст ошибку. Тогда /dev был лишь подкаталогом корневой файловой системы. И созданные файлы устройств существовали там всегда, а MAKEDEV запускался при необходимости. Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал устройства, о которых ядро предоставляло информацию (т.е. которые реально существуют). У такого подхода были недостатки: излишние обращения к ядру, по сути двойное перечисление устройств, понижающие скорость загрузки, необходимость поддержки в пространстве пользователя. Всё это усложняло использование системы во встраиваемых устройствах. Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. ```
