Re: DevFS и прочие

вс, 31 июл. 2022 г. в 14:27, Артём Н. <[email protected]>:

>
> В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в
> /dev, просто ради любопыства, там будут устройства, выставленные ядром.
>

Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный
элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока
udev наплодит там нужные ноды.


>  > Кажется, нельзя было например попросить систему всегда давать
> определенное
>  > имя сетевой карте с определенным мак-адресом
>  > (сейчас через udev это легко делается)
>
> Но это же делает набор правил уже *после* того, как устройство было
> выставлено драйвером.
> Или я что-то неправильно понимаю?
>
>
>  > Фишка udev еще в том, что пользователь настраивает правила, имея
>  > возможность давать устройствам имена,
>  > запускать скрипты при их появлении, запрещать какие-то устройства итд.
>
> Я так понимаю, что devfsd, который был до него, этим тоже занимался?
>
> запускать скрипты при их появлении, запрещать какие-то устройства итд.
>

Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было
предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не
составит никакого труда. То есть да - во многом идеи, которые вложены в обе
подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе
доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили
изучить?

От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то,
что через /proc задавался путь программы, которая будет запускаться ядром,
если требуется какое-то действие. Это называлось usermode helper. В случае
с udev программу запускает юзер один раз, и она общается с ядром по
интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать
параметры, исходя из которых юзер может кастомизировать
присваиваемые названия нодам и устройствам, а также задавать права доступа
к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так
далее. Наверное, было можно заморочиться и сделать подобное с devfs, но
решили отказаться потому что придумали как сделать это всё более чисто и
без необходимости писать и самое главное поддерживать в ядре и в драйверах
кучу кода, отвечающего за devfs.



-- 
With best regards
  Maksim Dmitrichenko