Re: DevFS и прочие
Спасибо. > Видимо это и есть ответ на ваш вопрос:) Похоже, что да, и ответ полный: написано подробнее и точнее, чем мой текст. Мне остаётся это только в "художественном стиле" переписать, и всё. 31.07.2022 20:03, IL Ka пишет: Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? Не совсем 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 Видимо это и есть ответ на ваш вопрос:)
Re: 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 Видимо это и есть ответ на ваш вопрос:)
Re: DevFS и прочие
Хотя, в целом, для врезки информации достаточно. 31.07.2022 14:48, Maksim Dmitrichenko пишет: вс, 31 июл. 2022 г. в 14:27, Артём Н. : В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды. ...
Re: DevFS и прочие
Ну, или точнее, про демон, который идёт вместе с devfs, там есть одно упоминание, но мне не вполне ясно, это про devfsd (который пришёл на замену devfs вместе с её демоном, как я понял) или нет? Т.е., udev к devtmpfs не имеет прямого отношения: это просто независимо работающие вещи, тут всё ясно. А что пришло на замену devfs не вполне ясно: то ли был параллельно какой-то devfsd (именно независимый от devfs "пользовательский" демон), то ли после, то ли сразу был udev...
Re: DevFS и прочие
> Если я правильно понимаю, то сейчас 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 пишет: вс, 31 июл. 2022 г. в 14:27, Артём Н. : В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды. > Кажется, нельзя было например попросить систему всегда давать определенное > имя сетевой карте с определенным мак-адресом > (сейчас через udev это легко делается) Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? > Фишка udev еще в том, что пользователь настраивает правила, имея > возможность давать устройствам имена, > запускать скрипты при их появлении, запрещать какие-то устройства итд. Я так понимаю, что devfsd, который был до него, этим тоже занимался? запускать скрипты при их появлении, запрещать какие-то устройства итд. Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не составит никакого труда. То есть да - во многом идеи, которые вложены в обе подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили изучить? От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, что через /proc задавался путь программы, которая будет запускаться ядром, если требуется какое-то действие. Это называлось usermode helper. В случае с udev программу запускает юзер один раз, и она общается с ядром по интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать параметры, исходя из которых юзер может кастомизировать присваиваемые названия нодам и устройствам, а также задавать права доступа к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так далее. Наверное, было можно заморочиться и сделать подобное с devfs, но решили отказаться потому что придумали как сделать это всё более чисто и без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs.
Re: DevFS и прочие
вс, 31 июл. 2022 г. в 14:27, Артём Н. : > > В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в > /dev, просто ради любопыства, там будут устройства, выставленные ядром. > Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды. > > Кажется, нельзя было например попросить систему всегда давать > определенное > > имя сетевой карте с определенным мак-адресом > > (сейчас через udev это легко делается) > > Но это же делает набор правил уже *после* того, как устройство было > выставлено драйвером. > Или я что-то неправильно понимаю? > > > > Фишка udev еще в том, что пользователь настраивает правила, имея > > возможность давать устройствам имена, > > запускать скрипты при их появлении, запрещать какие-то устройства итд. > > Я так понимаю, что devfsd, который был до него, этим тоже занимался? > > запускать скрипты при их появлении, запрещать какие-то устройства итд. > Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не составит никакого труда. То есть да - во многом идеи, которые вложены в обе подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили изучить? От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, что через /proc задавался путь программы, которая будет запускаться ядром, если требуется какое-то действие. Это называлось usermode helper. В случае с udev программу запускает юзер один раз, и она общается с ядром по интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать параметры, исходя из которых юзер может кастомизировать присваиваемые названия нодам и устройствам, а также задавать права доступа к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так далее. Наверное, было можно заморочиться и сделать подобное с devfs, но решили отказаться потому что придумали как сделать это всё более чисто и без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs. -- With best regards Maksim Dmitrichenko
Re: DevFS и прочие
Здравствуйте. > Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. > Кажется, нельзя было например попросить систему всегда давать определенное > имя сетевой карте с определенным мак-адресом > (сейчас через udev это легко делается) Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? > Фишка udev еще в том, что пользователь настраивает правила, имея > возможность давать устройствам имена, > запускать скрипты при их появлении, запрещать какие-то устройства итд. Я так понимаю, что devfsd, который был до него, этим тоже занимался? 31.07.2022 11:57, IL Ka пишет: Добрый день, Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. Кажется, нельзя было например попросить систему всегда давать определенное имя сетевой карте с определенным мак-адресом (сейчас через udev это легко делается) Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. Фишка udev еще в том, что пользователь настраивает правила, имея возможность давать устройствам имена, запускать скрипты при их появлении, запрещать какие-то устройства итд.
Re: DevFS и прочие
Ну, а я про что?
Андроид же, как я понял, хочет наоборот: сделать отдельный велосипед
("вернуть всё взад").
Не вижу тут ничего весёлого.
31.07.2022 09:41, Alexander Galanin пишет:
31.07.2022 02:17, Артём Н. пишет:
Понял, допишу. Спасибо.
Не хватало ещё очередного демона взамен udev, интегрированного в systemd.
Спасибо, повеселило. Ничего, что udev самым бессовестным образом лежит
_внутри_ репозитория systemd?
Re: DevFS и прочие
Добрый день, > > Затем разработчики Linux добавили в ядро поддержку devfs (не той, > которая используется сейчас). С ней возникли проблемы. Например, > пользовательские скрипты при загрузке должны были ожидать заполнения > иерархии и как-то синхронизироваться, необходимость явных вызовов изо > всех драйверов и т.д. Проблемы решались с переменным успехом, но система > не прижилась. > Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. Кажется, нельзя было например попросить систему всегда давать определенное имя сетевой карте с определенным мак-адресом (сейчас через udev это легко делается) > > Современный Linux монтирует в /dev файловую систему DevTmpFS, которая > сразу отображает все перечисленные ядром устройства, и поддерживающий > различные правила и события демон udev, при необходимости, > обеспечивающий её динамическую конфигурацию из пространства пользователя. > Фишка udev еще в том, что пользователь настраивает правила, имея возможность давать устройствам имена, запускать скрипты при их появлении, запрещать какие-то устройства итд.
Re: DevFS и прочие
31.07.2022 02:17, Артём Н. пишет: Понял, допишу. Спасибо. Не хватало ещё очередного демона взамен udev, интегрированного в systemd. Спасибо, повеселило. Ничего, что udev самым бессовестным образом лежит _внутри_ репозитория systemd? -- Alexander Galanin
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/
