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
