Подумываю о d-bus...

Но пока что top-15 это обработка utf8

Валидация utf8 там только в одном месте. (ЧСХ, в kdbus переписали маршалинг и сменили внутренний формат.)

Код передачи данных?

Что ты понимаешь под «кодом передачи данных»? Вызовы write() от буфера с готовым сообщением? Я думаю, что потери как бы не в них.

Если машинка одна, то я не вижу смысла делать рут по сети

А он есть. Я не хочу держать там копию базовой системы и её отдельно обновлять.

Валидация utf8 там только в одном месте. (ЧСХ, в kdbus переписали маршалинг и сменили внутренний формат.)

Что им мешало сменить формат в userspace? :)

Что ты понимаешь под «кодом передачи данных»? Вызовы write() от буфера с готовым сообщением? Я думаю, что потери как бы не в них.

Если не в них, зачем тащить код в ядро?

А он есть. Я не хочу держать там копию базовой системы и её отдельно обновлять.

Вместо этого ты хочешь постоянно обновлять initrd?

Пока что ядерные разрабы сделали бенчмарки и выяснили, что в ядро не уперлись.

См. начало дискуссии. Из бенчей это не следует.

Тормоза dbus-daemon'а могут принадлежать к одной из трёх категорий:

• возникающие ввиду того, что протокол такой (неисправимые)
• исправимые помещением в ядро
• исправимые без помещения в ядро

Где из того бенча следует то, что основные тормоза dbus-daemon'а исправимы без помещения в ядро?

См. начало дискуссии. Из бенчей это не следует.

Тормоза dbus-daemon'а могут принадлежать к одной из трёх >категорий:

возникающие ввиду того, что протокол такой (неисправимые)
исправимые помещением в ядро
исправимые без помещения в ядро

Где из того бенча следует то, что основные тормоза dbus-daemon'а исправимы без помещения в ядро?

См. начало дискуссии. Где доказательства того, что они не исправимы без помещения в ядро?

libqxt - QxtRpcPeer гонять между процессами можно 1) ключи QSharedMemory 2) сами данные ввиде QByteArray

Нет, это стандарт как-бы. И нравится тебе или нет, лучше делать через него. Тебе статусы сообщать нужно?

Это можно считать исчерпанием технических аргументов и началом перехода на личности?

Ну а хуле, если ты, кретин, в технической стороне вопроса слаб?

И раз уж так хочешь технических аргументов, где доказательства, что тех возможностей, которые ядро предоставляет (сокеты, события на них, shared memory) не хватает или они плохие?

А он есть. Я не хочу держать там копию базовой системы и её отдельно обновлять.

Есть сетевые ФС без всяких dbus. Даже в линуксе

Из бенчей это не следует.

Ты мудак? Там сплошные malloc и free

Это я тебе как человек пишущий ядро заявляю.

Кстати, а расскажи как писатель ядра (линукса, я так понял), как уже внутри ядра линукса потоки общаются между собой. Для общего развития интересно

возникли из сущности самого протокола

протокол, видимо, был выдан моисею на скрижалях

нечего ipc, который был сделан для склеивания гномосячьих ошмёток в подобие десктопа, делать в ядре

Гм... Там память общая, поэтому в основном модули просто экспортируют переменные / функции, которые могут дергать другие модули.

знакомство с QtDbus лучше начать отсюда - http://habrahabr.ru/post/185212/ может решишь, что ну его нафиг :-) ну и http://habrahabr.ru/post/185950/ в продолжение.

Я не увидел ничего страшного там.

возникающие ввиду того, что протокол такой (неисправимые)

Перенос в ядро их тоже не исправит.

исправимые помещением в ядро

Пока что нечего исправлять, так как тормозит юзерспейс.

исправимые без помещения в ядро

Бинго! kdbus бестрее потому «ЧСХ, в kdbus переписали маршалинг и сменили внутренний формат»

Ты же сам себя опровергаешь!

Не проще ли сразу потащить в ядро?

systemd и вяленого когда в ядре ждать?)

божички

а поднять свой процесс-сервер к которому конектятся клиенты и передают все что нужно друг другу

дбасы понапридумывали о ужас

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

Тогда, если большой пэйлоад кидать туда не собираешься - не вижу проблем.

Ибо где 10, там и 20. А если продумать интрефейс, то возможно кто то ещё будет сиё как то тыкать по этой шине, благо из скриптов она более чем доступна.

Кстати про интерфейсы, осмотри фридесктопные спеки, на предмет того, что ты делаешь, возможно, есть какой то стандартизированный интерфейс аля mpris.

просто экспортируют переменные / функции, которые могут дергать другие модули.

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

Ещё интересно, а в какой-нибудь фре в ядре тоже один общий address space? Если вопрос правильному адресату, конечно )

отправит логи на мыло и сделает ещё что-нибудь

Вот такие люди и запилили ядрёный nfs, заместо того, что бы у vfs нормальный интерфейс прокинуть.

а зачем в ядре ещё пространсто разделять?
предполагается, что в ядре говнокодеров нет. у ядра нет задач по защите от самого себя.

Вот такие люди и запилили ядрёный nfs

А что тебя не устраивает?

Ну ясно. В принципе логично, а то бы механизмы всяких блокировок было бы сложно сделать по-идее

Не знаю как про переменные, но про функции ответ не в тему немного.

Ты просто вопрос размыто задал.

Это ясно, что тамошний линкер подгружает модуль, и ему становятся видны символы из других модулей. Я именно про связь разных нитей между собой. Например, через указатель на какое-нибудь место в памяти. Какие там есть примитивы для обращения к нему помимо тривиальных мьютексов?

Ну... mutex, spinlock, rwlock, rcu, атомарные переменные, volatile переменные, etc. Тебя это интересует? :). Ты можешь думать о ядре как об одном процессе с общей памятью и кучей тредов. Общение между тредами с общей памятью везде примерно одинаковое.

Тебя это интересует? :)

Ага. Просто в DragonFlyBSD почти такая же фигня, как dbus, но для нитей в ядре, а не процессов в юзерспейсе. Там это называется портами и сообщениями. Вот интересно стало, есть ли в линуксе аналоги.

Кстати, а нити ядра смогут использовать kdbus для своих нужд, или он только на юзерспейс ориентирован?

Как минимум то, что в ядре vfs handle based, но наружу это никак не торчит, нету api которое могло бы использовать inode как хэндл.

А nfs - handle based, но вместо того, что бы прокинуть нормальный интерфейс от vfs для юзерспейса, мы имеем древний позикс и боль при написании сетевых файловых систем вне ядра, где им как бы не особо и место - ибо профита от этого никакого по сравнению с юзерспейсной реализацией.

Сомнения не должны быть обязательно на чём-то основаны.

Это называется троллинг. Нет смысла общаться с человеком которые на технические аргументы отвечает «и чо?».

Это называется троллинг. Нет смысла общаться с человеком которые на технические аргументы отвечает «и чо?».

И тут в тред врывается наш белый рыцарь с банхаммером наперевес. Ну давай, расскажи же нам, какие технические аргументы я проигнорировал (технические, а не «я хочу прищемить член дверью, почему операционная система мне этого не позволяет»)?

Кстати, а нити ядра смогут использовать kdbus для своих нужд, или он только на юзерспейс ориентирован?

На userspace.

Ну может ты и прав. Хотя где-то на stackoverflow я прочитал, что это, якобы, помогло им в скорости

Однажды у меня была задача, допилить ganeshaNFS - одну из юзерспейсных реализаций.

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

Вроде, как даже не голословно, но деталей я не помню, кроме основного затыка с хэндлами.

КМК, рыцарь не тебе предупреждение сделал.

Ну давай, расскажи же нам, какие технические аргументы я проигнорировал

Ты-то тут при чём? Посмотри кому я отвечал.

Гм... «И чо?» отвечал я :)

Да, как-то неловко вышло. Ну да ладно.

Эм, пардон, это случайное совпадение.

HTTP сервер в ядре уже был

http сервер, дорогуша, не имеет важности для работы gnu/linux системы. а хороший rpc - имеет. уже этого факта достаточно, чтобы затащить kdbus. криво/косо, но проблема производительности сервера dbus- решаема.

Wat? Я тут на протяжении тридцати комментариев пытаюсь выяснить ровно одну вещь: почему уважаемый кернел девелопер kirk_johnson считает, что kdbus не имеет права на жизнь только на основании того, что он kdbus (напомню, ревью кода ещё никем не проводился).

а хороший rpc - имеет. уже этого факта достаточно, чтобы затащить kdbus.

kdbus и rpc? Бугога. Максимум ipc.

По факту, кому нужно rpc давно используют zmq/nanomq и не жжужат. И никакой kdbus их не догонит по производительности.

что kdbus не имеет права на жизнь.

Хотя бы по причине бритвы Оккама. Даже не затрагивая технических недостатков.

криво/косо, но проблема производительности сервера dbus- решаема.

Я уже устал это повторять, но: необходимым для включения в ядро является невозможность сделать тоже самое в userspace.

Я тебе на протяжении тридцати комментариев пытаюсь объяснить, что должна быть веская причина совать код в ядро. А ты никак не можешь этого понять.

Хотя бы по причине бритвы Оккама

Принцип «бритвы Оккама» относится исключительно к теоретическим объяснениям фактов и не имеет никакого отношения к происходящему.

Даже не затрагивая технических недостатков.

Ты так говоришь, как будто они тебе известны.

Ты так говоришь, как будто они тебе известны.

А то, я целиком прочитал тред в LKML)

Принцип «бритвы Оккама» относится исключительно к теоретическим объяснениям фактов и не имеет никакого отношения к происходящему.

Очень удобно выдумать аксиому и ей разгромить оппонента, да.

что kdbus не имеет права на жизнь только на основании того, что он kdbus (напомню, ревью кода ещё никем не проводился).

«Что имеет право на жизнь а что нет» исключительно субъективная вещь. Поэтому сам вопрос не имеет смысла. Однако он не совсем это говорил. Он говорил что

а) dbus можно существенно ускорив переписав его

б) скорее всего он намекает что не надо тащить в ядро то что можно сделать в userspace.

По поводу первого пункта сам Леннарт признает что «текущая реализацию копирует каждый пакет 10 раз»: http://mirror.linux.org.au/pub/linux.conf.au/2014/Friday/104-D-Bus_in_the_ker...

напомню, ревью кода ещё никем не проводился

Наркоман что ли? Многие проблемы kdbus (например, с capabilities) были выявлены как раз в ходе этого самого кода мать твою ревью.

Во-первых, это не ревью, это «Энди поглядел на доку и баттхёртнул». Сам найдёшь место, где он говорил, что это не ревью.

Во-вторых, capabilities — это, согласно Линусу, не проблема.