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"

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

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

tailgunner ★★★★★
()

Andrew Morton: "Lol, devfs"

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

Sekai
()

>Andrew Morton: "Lol, devfs"

мож "LOL" ?

eR ★★★★★
()

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

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

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

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

arsi ★★★★★
()

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> Ну почему нельзя просто в драйвере при инициализации устройства создавать этот файл?..

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

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

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

const86 ★★★★★
()
Ответ на: комментарий от DNA_Seq

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

Да, многие так думали и поэтому сейчас оттуда усиленно выгребают мусор в /sys и другие места

frame ★★★
()

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

isden ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

unrealix
()
Ответ на: комментарий от isden

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

>> 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 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

>Adam Richters rewrite the we never ended up merging

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от wyldrodney

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

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

LordAily
()

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

linux4ever
()
Ответ на: комментарий от Macil

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

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

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

Какой бред :)

monika
()
Ответ на: комментарий от Macil

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

Нет.

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от isden

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

только для выставления прав, отличных от default'ных

AEP ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

Macil ★★★★★
()

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

babich
()
Ответ на: комментарий от Macil

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Macil

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

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

monika
()
Ответ на: комментарий от Macil

>загрузки фирмвари без юзерспейс утилит?

Это давно решено - встраивай фирмварь статически в ядро.

monika
()

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Macil

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

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

AEP ★★★★★
() автор топика
Ответ на: комментарий от AEP

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от monika

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

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

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

<Ъ>

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 ★★★★★
()
Ответ на: комментарий от Macil

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Macil

> объясни.

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

tailgunner ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

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

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