LINUX.ORG.RU

Devtmpfs - новое решение для заполнения /dev

 , ,


0

0

Kay Sievers послал в LKML патч, реализующий создание tmpfs на ранней стадии инициализации ядра и динамическое заполнение получившейся файловой системы. После монтирования корневой файловой системы, этот экземпляр tmpfs перемонтируется ядром в каталог /dev. Таким образом, "init=/bin/sh" работает без каких-либо статических устройств и вспомогательных программ. Все устройства имеют по умолчанию владельца root, группу root и права 0600, но эти параметры можно изменить (например, с помощью chown, chmod или udev).

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

Реакция других разработчиков:

Andrew Morton: "Lol, devfs"

Greg KH: "да, devfs, но сделанная как надо"

Alan Cox: "это убирает проблему из userspace, но добавляет ее в ядро, да так, что ее не выкинуть в swap"

>>> Подробности

Re: Devtmpfs - новое решение для заполнения /dev

Придурки Сиверс и Хартманн снова в деле.

tailgunner ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

А по ссылке:

Warning: fopen(http://local.xml.lkml.org:4444/thread.php?origin=1098312) [function.fopen]: failed to open stream: Connection refused in /srv/lkml.org/scripts/getmail.php on line 93

Давали бы линки на indiana.edu

http://lkml.indiana.edu/hypermail/linux/kernel/0904.3/03133.html

http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/00006.html

tailgunner ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Andrew Morton: "Lol, devfs"

lol

mamay_cozak ()

Re: Devtmpfs - новое решение для заполнения /dev

Весело у них там в LKML

На ЛОРе им бы понравилось

LordAily ()

Andrew Morton: "Lol, devfs"

Коротко и ясно.

Sekai ()

Re: Devtmpfs - новое решение для заполнения /dev

>Andrew Morton: "Lol, devfs"

мож "LOL" ?

eR ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Andrew Morton: "Lol, devfs"

Согласен :)

Slackware_user ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Нововведение рассчитано в первую очередь на рынок мобильных устройств, где с целью экономии ресурсов производители избегают использования udev.

> Alan Cox: "это убирает проблему из userspace, но добавляет ее в ядро, да так, что ее не выкинуть в swap"

swap на «мобильных устройствах, где с целью экономии ресурсов производители избегают использования udev»? о_О а куда свопить-то, в нанд-флеш?

по теме: отлично, теперь можно и динамические номера устройств =)

arsi ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

Меня всегда удивляло, что для создания файла устройства в /dev надо либо в ручную что-то городить, либо udev использовать... Ну почему нельзя просто в драйвере при инициализации устройства создавать этот файл?.. Или система не достаточно гибка? Отсюда вопрос: неужели мои мечты сбылись? Можно подробнее, теперь можно создавать /dev/mylol прямо из драйвера?

I-Love-Microsoft ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Для этого есть /proc =)

Для этого есть sysfs. Кстати, странно, что в ней встречаются файлики dev с номерами соответствующего устройства. Почему бы им не быть непосредственно устройствами? Вышло бы как раз всем хорошо. На всяких embedded можно их юзать напрямую, а на более мощных системах можно заюзать udev, который расставит симлинки.

const86 ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

Ирония в том, что Greg KH как раз больше всех поработал глоткой, чтобы похоронить саму идею devfs, и был основным аффтаром udev (Sievers - текущий мэйнтейнер). Теперь они наконец-то поняли, что именно devfs рулит. Клоуны тупые.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

> Таким образом, "init=/bin/sh" работает без каких-либо статических устройств и вспомогательных программ.

а для devfs нужен был демон если мне память не изменяет.

isden ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>Ирония в том, что Greg KH как раз больше всех поработал глоткой, чтобы похоронить саму идею devfs, и был основным аффтаром udev (Sievers - текущий мэйнтейнер). Теперь они наконец-то поняли, что именно devfs рулит. Клоуны тупые.

предвижу форк

unrealix ()

Re: Devtmpfs - новое решение для заполнения /dev

> для devfs нужен был демон если мне память не изменяет.

В devfs была встроенная схема именования, а демон был нужен для поддержки других схем. В результате имеем встроенную схему devfs против того же в devtmpfs.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от true_admin

Re: Devtmpfs - новое решение для заполнения /dev

> ты-то, конечно, круче их обоих вместе взятых

Мне приятно, что ты так думаешь.

> и никогда не ошибаешься.

Нерелевантно.

P.S. ветку почитай, я запостил работающие ссылки.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>Greg KH как раз больше всех поработал глоткой, чтобы похоронить саму идею devfs

Вот не надо только! Devfs была оочень большой проблемой в 2.6. Главным образом, в том, что ее аффтар-мейнтейнер исчез, а в самой devfs были очень хитрые race conditions. (Это к вопросу включения reiser4 в ядро).

Поэтому и пришлось городить огород с udev, поэтому юзерспейс-вариант нашел поддержку: погавкали-погавкали и перестали, никому не хотелось брать ответственность за долгосрочное "ядерное" решение.

А теперь, когда в ядре появилась определенная инфраструктура, к этому вопросу вернулись.

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>> Greg KH как раз больше всех поработал глоткой, чтобы похоронить саму идею devfs

> Вот не надо только!

Надо. Помнить историю вообще полезно.

> Devfs была оочень большой проблемой в 2.6

Разве что для тебя лично.

> Поэтому и пришлось городить огород с udev, поэтому юзерспейс-вариант нашел поддержку

Специально для знатоков истории: http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/00460.html

<Ъ>

It basically does re-introduce devfs under a different name, and from looking at the implementation it might not be quite as bad a Gooch's original, but it's certainly worse than Adam Richters rewrite the we never ended up merging.

</Ъ>

Что непонятно во фразе "but it's certainly worse than Adam Richters rewrite the we never ended up merging"? Это сказал Christoph Hellwig, а не какой-то хрен с горы^WЛОР.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>Разве что для тебя лично.

Ну-ну. С самого 2.6 в статусе DEPRECATED. Еще раз говорю, там были race-conditions, которые никто править не хотел, ментейнер исчез и перспектива была крайне паршива.

>Adam Richters rewrite the we never ended up merging

Ты еще Кона Коливаса вспомни. Если эту супер-пупер fs не была смержена, то виноват в этом Adam Richters и никто, блин, иной. Все. Точка.

Не можешь свою идею в какой-нибудь -mm ветке несколько лет содержать, перелопачивая код на каждый чих разработчиков основной - не достоин, значит, и иди лесом. ИМХО эта позиция правильная.

Конечно, разработчики немножко ссыкнули, это понятно. Но в те времена у ядра было много проблем, типа смены того же цикла разработки, и как следствие глюки, регрессии и т.п. Поэтому идея вынести часть не очень полезного функционала (с точки ядерного разработчика) в юзерспейс была очень заманчива.

Macil ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от wyldrodney

Re: Devtmpfs - новое решение для заполнения /dev

> Ты бы видел "обсуждение" патча для Vfat, правящего работу с длинными именами (всё патенты...).

я в английском длинный ноль
вишаю лкмл.дейли на русском

LordAily ()

Re: Devtmpfs - новое решение для заполнения /dev

Еще раз тронут udev, свалю либо в BSD, либо к пидо^W, либо куплю Win7, я больше не могу, уже надоело это охомячивание Лялега.

linux4ever ()

Re: Devtmpfs - новое решение для заполнения /dev

>> Разве что для тебя лично.

> Ну-ну. С самого 2.6 в статусе DEPRECATED.

И что? Проблемы где? Вот то, что вместо devfs заменили udev - это было проблемой, потому что devfs уже начали использовать.

> Еще раз говорю, там были race-conditions, которые никто править не хотел, ментейнер исчез и перспектива была крайне паршива.

Ты можешь говорить это сколь угодно много раз, если от этого тебе лучше. Я уже привел цитату о сравнительной идеологии и качестве кода тогдашней devfs, переписанной devfs и devtmpfs. Тебе есть что сказать по этому поводу?

> Если эту супер-пупер fs не была смержена, то виноват в этом Adam Richters и никто, блин, иной. Все. Точка.

> Не можешь свою идею в какой-нибудь -mm ветке несколько лет содержать, перелопачивая код на каждый чих разработчиков основной - не достоин, значит, и иди лесом.

Настоящий суровый мущина, и при этом идеалист. Какая прелесть.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>И что? Проблемы где?

Ты может быть и reiser4 пользуешь? С таким же уровнем аргументации? Типа состояние гонки - это уже не проблема. Типа исчезновение мейнтенера, который практически единственный в коде разбирался - это уже не проблема?

>Тебе есть что сказать по этому поводу?

Есть. Кесарю - кесарево. /dev используют юзерспейс программы - значит и отвечать за его состояние должны юзерспейс программы.

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Ты может быть и reiser4 пользуешь?

Нет.

> Типа состояние гонки - это уже не проблема

В коде, который используют люди, которые знают, что делают - ни разу не проблема.

> /dev используют юзерспейс программы - значит и отвечать за его состояние должны юзерспейс программы.

Ты, походу, даже не читал то, что обсуждаешь.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>которые знают, что делают - ни разу не проблема.

А исчезновение мейнтейнера?

>Ты, походу, даже не читал то, что обсуждаешь.

Хорошо, переформулирую по-лоровски: "devfs в любом своем виде - не нужен".

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>> которые знают, что делают - ни разу не проблема.

> А исчезновение мейнтейнера?

Тоже не проблема - нарисовался второй.

> переформулирую по-лоровски: "devfs в любом своем виде - не нужен".

Поговори об этом с Greg KH и Kay Sievers.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>Тоже не проблема - нарисовался второй.

И утверждал, что в коде полхо разбирается. И править проблемы, указанные товарищами не спешил, например несовместимость схемы наименования devfs с LFS.

А вообще, просвети, зачем devfs нужна? В каких-таких ситуациях она будет заруливать юзерспейс-решение?

Например, как решить вещи типа выбора нужного модуля и загрузки фирмвари без юзерспейс утилит?

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

Новость прочитал, но не понял.

babich ()

Re: Devtmpfs - новое решение для заполнения /dev

>> Тоже не проблема - нарисовался второй.

> И утверждал, что в коде полхо разбирается.

Он был готов переписать код, который все почему-то резко возненавидели. И он это сделал. И сделал это лучше, чем резвый паренек из новости. Но код резвого паренька уже попал в linux-next.

> А вообще, просвети, зачем devfs нужна? В каких-таких ситуациях она будет заруливать юзерспейс-решение?

По ссылкам это разъяснено.

tailgunner ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>переформулирую по-лоровски: "devfs в любом своем виде - не нужен".

формулируй как хочешь - сути это не меняет, состояние /dev это забота ядра - только оно знает о своем внутреннем состоянии и юзерспейс тут никак не вписывается, это хорошо известно например эмбендщикам которым приходится статически создававать файлы устройств на все случаи жизни. То что тебе это не нужно - говорит лишь о твоем ограниченном понимании вопроса.

monika ()

Re: Devtmpfs - новое решение для заполнения /dev

Может быть так оно и надо. И у того, и у другого варианта свои плюсы и минусы

vasily_pupkin ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> Например, как решить вещи типа выбора нужного модуля и загрузки фирмвари без юзерспейс утилит?

В embedded-решениях такие задачи не стоят. Все нужные модули можно вкомпилировать в ядро, вместе с фирмварью (CONFIG_FIRMWARE_IN_KERNEL)

AEP ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>> Например, как решить вещи типа выбора нужного модуля и загрузки фирмвари без юзерспейс утилит?

> В embedded-решениях такие задачи не стоят.

Ну почему же, выгоды модулей во встраиваемых системах те же, что и в обычных. Другое дело, что devfs этому не мешает.

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>По ссылкам это разъяснено.

Ничего там не разъяснено. Какие-то высосанные из пальца утверждения. Особенно не понятно как будут передаваться факты присоединения устройств юзерспейс утилитам.

Сейчас, по крайней мере, через uevent.

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>не нужно - говорит лишь о твоем ограниченном понимании вопроса.

Достали т.н. "эмбендщики", учитывая тот факт что по-настоящему встраиваемых систем осталось мало и львиная их доля под линуксом не работает.

Ну неужели не понятно, что "просто так" не бывает НИЧЕГО!!! Если что-то занимает меньше - значит были принесены в жертву функционал или удобство или еще чего-то.

Ну хватит, блин сувать в ядро, что сувать не должно. То что т.н. "эмбендщики" не могут осилить udev или АНАОЛОГ udev (uevent, блин, никто не отменял), не значит что ЛИЧНО для них должны делаться изменения в ядре.

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

>> По ссылкам это разъяснено.

> Ничего там не разъяснено.

Ты просто не сходил по ссылке.

<Ъ>

Unmodified udev versions will run just fine on top of it, and will recognize an already existing kernel-created device node and use it.

...

udev works just fine with or without it. When udev receives the event, it looks if there is an already existing node, and if yes, it just applies the defined permissions/ownership to it. The final decisionss are still made in udev. </Ъ>

tailgunner ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> т.н. "эмбендщики" не могут осилить udev или АНАОЛОГ udev (uevent, блин, никто не отменял), не значит что ЛИЧНО для них должны делаться изменения в ядре.

Бгг. Ты настолько невежественен и нагл, что это даже мило %)

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от tailgunner

Re: Devtmpfs - новое решение для заполнения /dev

>Ты просто не сходил по ссылке.

Да ходил я по ссылке, и приведенное тобой в секции Ъ читал.

Вот лично я уважаю принцип единоличной ответственности. Как минимум, этот принцип позволяет избегать очень трудноуловимых глюков, возникающих при ВЗАИМОДЕЙСТВИИ двух систем. Т.е. система A работает правильно, система B работает правильно. А вот при взаимодействии получаются глюки.

Да, я осведомлен, что udev решает проблему на уровне начальной загрузки юзерспейса, а на уровне initrd все как в старые-добрые времена. Но вот скажите, мы что на уровне initrd тыкаем устройства горячего подключения или проводим какие-то серьезные модификации в конфигурации системы? Нет. Уровень initrd призван подготовить запуск init, и включение чего-то в ядро ИМХО мало поможет.

Macil ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

Тебе придется запихать в initrd или в initramfs базовые dev устройства типа zero, null, console, итп. Возможно sdaXX, причем не очевидно что там будет libsata. Вобщем шопопало.

vasily_pupkin ★★★★★ ()

Re: Devtmpfs - новое решение для заполнения /dev

> объясни.

Эмбедщики всё осилили. В busybox входит mdev, в более "толстых" системах может использоваться обычный udev (в составе минимальной инсталляции Дебиана, к примеру).

tailgunner ★★★★★ ()
Ответ на: Re: Devtmpfs - новое решение для заполнения /dev от vasily_pupkin

Re: Devtmpfs - новое решение для заполнения /dev

>initrd или в initramfs базовые dev устройства типа zero, null, console

Какие-то проблемы?

>причем не очевидно что там будет libsata

libsata там по-определению не будет, равно как загруженного можуля корневой ФС.

Macil ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.