для чего нужен mdev?

Какой mdev? Который альтернатива udev?

Для случаев, когда devtmpfs - мало, а udev - много.

Так для чего нужны-то? И udev? И devtmpfs?

Что бы руками /dev/sdb1 не создавать, когда ты фотоаппаратик в убогий китайский юзб воткнул.

mdev не альтернатива udev в нём не используется netlink, а он стартует как /sbin/hotplug, что криво и тормозно

что криво и тормозно

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

при загрузке эвенты летят куда быстрее, чем «20 раз в секунду». а если система нагружена не только вконтактиком, можно нарваться на oom при подключении фотика

при загрузке эвенты летят куда быстрее, чем «20 раз в секунду»

Это не hotplug

а если система нагружена не только вконтактиком, можно нарваться на oom при подключении фотика

Давай, цепляй фотик к нагруженному серверу. А некоторые девайсы вообще на приборе крутили подключение девайсов.

а ты, оказывается, ещё и udev хейтишь? :3

Это не hotplug

угу, и модули подгружаются божьим духом

А некоторые девайсы вообще на приборе крутили подключение девайсов

в фортунки

Не, интел, не хейчу. Но на моем старом домашнем сервачке его нет.
И на армовом девайсе с гентой тоже.

Даже на ноуте с той же гентой я безпроблемно выпиливал udev и всё работало.

и модули подгружаются божьим духом

хз, у меня всё в ядро вкомпилено.

в фортунки

Потом расскажешь, зачем на embedded плату внутри прибора втыкать фотик ;)

а у всех остальных дистрибутивное ядро, и mdev тормозил бы загрузку, если бы использовался

Никогда не понимал стремления выпиливать всё подряд. Ну да ладно. Неужели было настолько важно сэкономить десять метров места на диске (и четыре метра RSS)?

цепляй фотик к нагруженному серверу

так и делаю, если мой локалхост назвать «сервером»

Неужели было настолько важно сэкономить десять метров места на диске (и четыре метра RSS)?

Зачем лепить лишние сущности, если mdev уже есть в системе?

Зачем трахаться с системой, заменяя (например) evdev на какое-то говно мамонта, если можно просто поставить udev?

(Нет, я люблю трахаться с системой, но считаю, что это нужно делать обоснованно, и по возможности не переть против апстрима.)

и по возможности не переть против апстрима

Для таких возможностей винда с макосью есть.

evdev … udev

не вижу связи

казалось бы, при чём тут systemd?

Можно подумать, что основная задача udev это использовать netlink, а не создавать файлы-устройства и переименовывать их. При этом mdev может работать из под nldev, который слушает netlink сокет.

По вашей логике ″ifcofing″ не альтернатива ″ip addr″, потому что тоже не использует netlink.

А она есть. Судя по гентубуку, evdev зависит от udev.

Расслабься, теперь любой тред про core userspace будет рано или поздно сводиться к systemd-срачу. Я лично за этим слежу :3

Не вижу. :( curl -s http://wiki.gentoo.org/wiki/Evdev | grep -i udev

а не создавать файлы-устройства

из udev код для этого удалён, устройства создаёт devtmpfs

дело не в netlink, а в том что не использовать его, а спавнить соотню процессов — криво и тормозно

а так ifcofing″ не альтернатива ″ip, но не из-за netlink

http://wiki.gentoo.org/wiki/Mdev#Will_mdev_work_on_my_system.3F

Note
Recent versions of evdev x11-drivers/xf86-input-evdev and Chromium www-client/chromium require udev. They will not build without it.

из udev код для этого удалён, устройства создаёт devtmpfs

Что, и /dev/disk/by-uuid/* создаёт ядро? И во всех правилах udev не найти ни одного слова ″SYMLINK″? То, что udev создаёт симлинк, а не настоящий файл-устройство, сути не меняет. Скрипту/процессу не важно, что он открывает в /dev (файл или симлинк), главное, чтобы в /dev/ существовало нужное имя.

а спавнить соотню процессов — криво и тормозно

Почтовые сервера спокойно работают кучей процессов. И от того, что один код работает медленне другого, не значит, что он не может его заменить. Может я использую неправильное слово, для меня «альтернатива» значит нечто, способное заменить другое, возможно не полностью, но в достаточной степени, как «альтернативные источники энергии».

и /dev/disk/by-uuid/*

это симлинки

То, что udev создаёт симлинк, а не настоящий файл-устройство, сути не меняет

зачем ты пытаешься спорить с реальностью и тут же выкручиваться

при отключении-подключении мыши прилетает 5*2 эвентов. ты реально считаешь, что спавнить 10 процессов только для того, чтобы обнаружить, что правил для них нет и действия не требуется — это нормальная практика? тебе на govnokod.ru

что один код работает медленне другого

я уже писал выше, что это может привести к oom. вот комментарий из конфига ядра, ты споришь с разработчиками ядра:

CONFIG_UEVENT_HELPER:
... This should not be used today, because usual systems create many events at bootup or device discovery in a very short time frame. One forked process per event can create so many processes that it creates a high system load, or on smaller systems it is known to create out-of-memory situations during bootup.

вот это — https://code.google.com/p/chromium/issues/detail?id=387287 ? хромиумопроблемы ведь, разве нет? не зря у него udev в зависимостях же. я бы избавился от udev, если для mdev можно такие же заскриптованные правила на события набросать, как для udev (или в идеале более красивое решение)

с evdev что-то странное тогда, он конечно создаёт свои ноды в /dev, но это ведь не повод привязываться к udev

В линуксе всё может привести к OOM. mdev используют вместо udev. Про nldev я уже написал.

ты реально считаешь, что спавнить 10 процессов только для того, чтобы обнаружить, что правил для них нет и действия не требуется — это нормальная практика? тебе на govnokod.ru

А ты реально считаешь, что правильнее всё время занимать часть ОЗУ правилами для подключаемых устройств, если устройство, может быть, будет подключено раз в год? Особенно, если речь про микросистемы, где не ОЗУ особо нет, ни swap'а?

зачем ты пытаешься спорить с реальностью и тут же выкручиваться

Это ты зачем то читаешь сообщение по строкам и начинаешь отвечать, не дочитав до конца. Если в fstab'е прописано монтирование по /dev/disk/by-uuid/* то без разницы, что там будет в это каталоге — файлы или симлинки. Главное, чтобы udev их создал.

В линуксе всё может привести к OOM

ага, и к сегфолту. предлагаешь писать говнокод без проверок

ты не знаешь, как работает твой nldev? ровно так же спавнит mdev на каждый чих

правильнее всё время занимать часть ОЗУ правилами

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

Если в fstab'е

накласть что там в фстабе

mdev используют вместо udev

мало ли какую глупость где делают

Я не предлагаю писать код без проверок, но проверять то, что произошёл ООМ — как? Если ООМ, то либо приложение «убъют», чтобы освободить память, либо оно не заметит, что был ООМ. Если в системе так мало ОЗУ, что она не может позволить себе запуск нескольких процессов mdev, так там и обычные sh-скрипты могут не работать.

ты не знаешь, как работает твой nldev? ровно так же спавнит mdev на каждый чих

nldev не мой, я вобще не программист. Но, если ты что-то знаешь в Си, можешь глянуть исходник: http://git.r-36.net/nldev/tree/nldev.c там всё просто. И ещё можешь почитать ″man waitpid()″. Ну так как тебе всё одно будет лень это делать, то поясню, nldev запускает mdev и ждёт завершения его работы. Да, на каждый чих будет запущего по mdev, но последовательно, а не одновременно.

сколько оно там не занимает, это на порядок меньше памяти требующейся на форк одного mdev,

Иди, примерь корону. Ты переплюнул царя, даже он не додумался утверждать, что fork() (ОДИН fork()) требует в 10 раз больше памяти, чем работающий процесс. Теперь ещё объясни, что такого происходит про fork(), а то везде пишут, что fork() как бы вобще памяти не занимает, есть же copy on write, вот exec() возмёт память размером с исполняемый процесс, но опять же, не в десять раз больше.

А ты предлагаешь постоянно держать в памяти и udev и кучу его правил, хотя эта память могла бы быть использована под дисковый кеш. И ради чего? Чтобы можно было дрочить флешкой? Не всё, что льётся в netlink-сокет приводит к запуску hotplug'а. Чтобы достичь сотни в секунду нужно напрячься.

накласть что там в фстабе

Ну наклади, будут проблемы при boot'е.

проверять нужно до, в /proc/meminfo, и не приводить к oom в первую очередь

там и обычные sh-скрипты могут не работать

они могут и не использоваться

waitpid

ну ок, что не отменяет кривость и тормозность этой поделки. кстати, там на описываемый случай даже есть костыль disableoom()

утверждать, что

полегче с фантазиями. ты рассказывал, что правила что-то там занимают, я ответил что спавн нового процесса mdev займёт гораздо больше

везде пишут, что fork()

ещё почитай как в unix запускаются процессы — за fork() следует execve(). в нём стартуется другой бинарник, между ними не будет никакого cow, совсем

а на сам fork может не хватить памяти тупо из за исчерпания адресного пространства, в то время как уже запущеный udev с netlink будет спокойно работать

кучу его правил

и сколько же они занимают, а? особенно по сравнением со спавном нового процесса mdev?

И ради чего?

не знаешь, какие и в каких количествах эвенты могут прилететь, и автоматически решаешь что «мало» и «пофиг»?

Не всё, что льётся в netlink-сокет

конкретные цифры

эта память могла бы быть использована под дисковый кеш

по дефолту считаем, что она занята спавнящимся mdev

проверять нужно до, в /proc/meminfo, и не приводить к oom в первую очередь

Чего проверять? В любой момент времени любой процесс может захавать всю память.

они могут и не использоваться

И ООМ может не наступить при использовании mdev. Ещё много чего может быть.

ну ок, что не отменяет кривость и тормозность этой поделки. кстати, там на описываемый случай даже есть костыль disableoom()

А кому там нужна скорость в определении новых устройств? fork()+exec() отработают быстрее, чем время на вытаскивание флешки из кармана, подключении её в разъём и её определение системой. То есть, если в nldev обращаются к ″/proc/self/oom_score_adj″ это костыль, а когда в udev делаю то же самое, это нормально.

я ответил что спавн нового процесса mdev

Ты использовал слово «форк». Хорошо, пусть будет спавн. Процесс udev содержит код, который читает из netlink сокета, код, который обрабатывает правила и сами правила. Процесс nldev содержит код, который читает из netlink сокета, и код, который запускает mdev. Процесс mdev содержит код, обрабатывающий правила и сами правила.

Один процесс заменён парой других. Откуда тут разница на порядок в объёме занимаемого ОЗУ?

а на сам fork может не хватить памяти тупо из за исчерпания адресного пространства, в то время как уже запущеный udev с netlink будет спокойно работать

Исчерпание адресного пространства? Мы что, про 16 битные системы говорим? А если нет места на fork()/exec() такого небольшого процесса, как mdev, то нафиг нужна такая система? Ну будет работать udev, а ничего полезного он не сделает, ни mount не запустит, чтобы подмонтировать флешку, ни xinput, не запустит, чтобы отключит тачпад.

и автоматически решаешь что «мало» и «пофиг»?

Да, потому что mdev используют и эмбедид с ним работают. А конкретные цифры приводи сам, а то, сначала у тебя там «20 событий на подключение флешки», потом «сотню в долю секунды» — одновременное втыкание 5 флешек, что-ли?

по дефолту считаем, что она занята спавнящимся mdev

С чего это ему спавнится, если никто ничего не подключает к системе?

Чего проверять? В любой момент

если проверять, а не говнокодить — не может

И ООМ может не наступить

у не-говнокодеров расчёт ведётся на worst case

А кому там нужна

нет смысла делать хуже

Один процесс заменён парой других. Откуда тут разница ... в объёме занимаемого ОЗУ?

оттуда

на порядок

ты всё морозишь что правила udev, сколько то-байт занимающие, вот по сравнению с ними

А конкретные цифры приводи сам

я привёл выше, а ты разводишь кукаретинг

С чего это ему спавнится, если никто ничего не подключает к системе?

с того, например, что usb устройства любят отваливаться, те же модемы

потому что mdev используют и эмбедид

на твоём локалхосте? в том же openwrt используется procd, безо всяких спавнов говно-mdev

если проверять, а не говнокодить — не может

Бесполезно проверять /proc/meminfo. Запусилось несколько процессов, почти одновременно прочитали meminfo, решили что памяти достаточно, все сделали malloc, а памяти всем не хватило. От OOM из-за malloc как-то страхует /proc/sys/vm/overcommit_memory = 2.

От OOM из-за exec() вобще никаких гарантий. Нельзя так просто определить сколько ОЗУ будет занято запускаемым процессом, ведь помимо самого бинарника могут загружатся динамические библиотеки.

Проверки, основанные на чтении /proc/meminfo только замусорят код демона, делая его менее понятным. Или давай примеры таких правильных демонов, которые что-то там проверяют в /proc/meminfo.

что usb устройства любят отваливаться, те же модемы

Отвал одного usb устройства к страшному не приводит, там все достаточно неспешно. Я подключал флешку через цепочку usb удлинителей, чтобы вызвать её неустойчивую работу у смотрел логи. Всяких сообщений и событий много, но они размазаны во времени. Поэтому если у устройства один usb-порт и туда подлючается что-то одно, нету никаких ужосов с тысячами событий. Проблемы начинаются, когда устройств много, допустим, неустойчиво работает многопортовый usb-хаб.

procd появился относительно недавно, до этого там был hotplug2. А неумеренным спавном процессов страдал udevd в «молодости», потом его усмирили, ограничя кол-во процессов udevd в зависимости от процессора и объёма ОЗУ.

можно префокаться и спавнить прцессы заранее

Или давай примеры

http://doc.qt.digia.com/qtextended4.4/syscust-oom.html#the-qt-extended-oom-so...

Чем больше процесс съест памяти префорком тем раньше придёт ООМ.

Документ про Qt Extended OOM Solution изучил. Ну пытаются предугадать OOM, анализируя кол-во page fault'ов. Зачем то меняют частоту проверки, когда сумма MemFree, Buffers и Cached близка к MemTotal (хотя в обычной системе только в начале работы кэш пустой, а потом свободной памяти как бы нет, всё отдано под кэш). Ну не важно, в общем предугадали, что скоро будет OOM, пытаются остановить менее важные процессы.

Ну получаем еще один OOM-killer, только не в ядре, а в user-space. Не очень надёжный, они сами пишут:

However, in case no warning signs are detected, and a real OOM condition forces Linux to choose a process to kill, the Qt Extended solution also uses the kernel's oom_adj infrastructure to prevent the kernel from choosing the Qt Extended server or some other critical process for killing.

То есть они сами признают, что может быть случай, когда ″warning signs are detected″, то есть не предугадали OOM.

При этом от самого процесса мало что зависит, его заранее в [[oom_adj]] определили как ″expendable″. И я не увидел, есть ли там механизм, препятствующий запуску второстепенных процессов при Low/Very Low свободной памяти.