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