> Если я правильно понимаю, то сейчас 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, Артём Н. <artiom14@yandex.ru>:В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром.Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды.> Кажется, нельзя было например попросить систему всегда давать определенное > имя сетевой карте с определенным мак-адресом > (сейчас через udev это легко делается) Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? > Фишка udev еще в том, что пользователь настраивает правила, имея > возможность давать устройствам имена, > запускать скрипты при их появлении, запрещать какие-то устройства итд. Я так понимаю, что devfsd, который был до него, этим тоже занимался? запускать скрипты при их появлении, запрещать какие-то устройства итд.Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не составит никакого труда. То есть да - во многом идеи, которые вложены в обе подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили изучить? От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, что через /proc задавался путь программы, которая будет запускаться ядром, если требуется какое-то действие. Это называлось usermode helper. В случае с udev программу запускает юзер один раз, и она общается с ядром по интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать параметры, исходя из которых юзер может кастомизировать присваиваемые названия нодам и устройствам, а также задавать права доступа к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так далее. Наверное, было можно заморочиться и сделать подобное с devfs, но решили отказаться потому что придумали как сделать это всё более чисто и без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs.