форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
Сообщение от opennews (??) on 27-Окт-16, 19:23
В списке рассылки разработчиков ядра Linux предложена (https://lkml.org/lkml/2016/10/26/963) для обсуждения реализация новой шины обмена сообщениями Bus1 (http://www.bus1.org/), пришедшей на смену шине kdbus (https://www.opennet.me/opennews/art.shtml?num=41810), которую в свой время не удалось продвинуть в основной состав ядра. Bus1 разработан с нуля и концептуально ближе к IPC-маханизмам Android Binder (https://developer.android.com/reference/android/os/Binder.html), Cap'n Proto (https://capnproto.org/) и seL4 (https://sel4.systems/), чем к kdbus. Bus1 реализован в виде универсального модуля для ядра Linux, не требующего наличия каких-либо обязательных компонентов в пространстве пользователя. Код Bus1 распространяется (https://github.com/bus1/bus1) под лицензией LGPLv2.1+. Bus1 предоставляет объектно-ориентированный IPC-интерфейс для организации обмена данными между процессами (пирами), сочетающий легковесность и масштабируемость организации совместной работы с такими возможностями, как модульность, разделение привилегий, учёт ресурсов, изоляция и сокрытие информации (https://en.wikipedia.org/wiki/Information_hiding). Работа с объектами реализована через легковесные дескрипторы. Поддерживается доставка данных как в режиме точка-точка, так и в режиме мультикаст (от одного отправителя к группе получателей) с гарантированным сохранением порядка следования данных. На базе Bus1 в пространстве пользователя могут быть реализованы различные UAPI для обмена сообщениями, включая  Binder UAPI. Bus1 работает децентрализовано и только  в локальных контекстах, не предоставляя общего глобального состояния совместного доступа или глобальных блокировок. Ключевыми примитивами в Bus1 являются узлы и дескрипторы: узлы представляют объекты локальных пиров (https://ru.wikipedia.org/wiki/Peer), а дескриптор выполняет роль указателя на узел. Узлы могут создаваться любым пиром, всегда оставаясь закреплёнными за своим создателем. Дескрипторы, ссылающиеся на узлы, могут передаваться с прикреплением сообщений в качестве вспомогательных данных. После доставки дескриптора, на стороне получателя создаётся его копия, которая указывает на тот же узел, что и оригинальный дескриптор. Любой пир может отправлять  сообщения через один из своих дескрипторов, которые будут направлены владельцу связанного с дескриптором узла. Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно. Дескриптор в данном случае выступает в роли механизма для предоставления эксклюзивного доступа, при этом доступ можно делегировать другим пирам просто передавая дескриптор. Права доступа не отзываются, но владелец узла в любой момент может его удалить и разрушить таким образом все привязанные дескрипторы. Пиры не могут адресоваться напрямую, полностью отделены и могут взаимодействовать с другими пирами только через узлы и дескрипторы. Со стороны все узлы равнозначны и невозможно определить принадлежат узлы одному пиру или разным. URL: https://lkml.org/lkml/2016/10/26/963 Новость: http://www.opennet.me/opennews/art.shtml?num=45382
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+4 +/–
Сообщение от Аноним (??) on 27-Окт-16, 19:23
Ну вот, движение к концепции микроядра идёт неизбежно. Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+2 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 19:29
	> Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово. Думаю, определенную роль сыграли недавние remote root with one IP packet (CVE-2016-7117) и remote DoS with one IP packet (CVE-2016-7039, CVE-2016-8666).
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	70. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–1 +/–
	Сообщение от Аноним (??) on 29-Окт-16, 01:04
	это как-то противоречит изначальному тезису?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–9 +/–
	Сообщение от Andrey Mitrofanov on 27-Окт-16, 19:45
	> Ну вот, движение к концепции микроядра идёт неизбежно. Будет вам "микро"-ядро от Лёнарта... > Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз. > угрозы безопасности и требования к надёжности - таки говорят своё веское > слово.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–9 +/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 19:52
	Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+9 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:39
	> Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов. Для тех, кто в курсе про разные назначения разных видов IPC, звучит как "TCP фигня, ICMP допилить - и то больше шансов".
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	24. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 21:50
	Расширить до нужного состояния SysV очереди хотя бы возможно. А это... Какой-то архитектурный урод с самого начала.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	30. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+6 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 22:53
	> Расширить до нужного состояния SysV очереди хотя бы возможно. Мультикаст фифо с неограниченным количеством подписчиков - это круто. Ждем от вас патча.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 23:22
	Не вижу ничего ужасного. Можно управление подписчиками вытащить в отдельного демона, если уж так страшно. А можно и не вытаскивать. Можно и число подписчиков сделать ограниченным - тоже невелика беда, для любых реальных задач 128 непосредственных подписчиков, пожалуй, хватит. А больше нужно только для редких system-wide событий, которые один хрен будут обрабатываться какими-нибудь демонами per-user.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	51. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 08:15
	Не болтай, делай, а когда сделаешь тогда и приходи болтать.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	69. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Alex (??) on 28-Окт-16, 19:30
	Поздравляю, ты изобрел dbus. Именно его и хотели отправить на свалку, заменив kdbus
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	89. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:56
	> 128 непосредственных подписчиков, пожалуй, хватит. Ух ты, 640 килобайтов хватит всем более не в моде. Пожалуй я погорячился с предложением пойти в рассылку и предложить архитектуру. Если ты такой архитектор - лучше вещай на опеннете.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	68. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Baz on 28-Окт-16, 19:07
	да куда проще допилить парой мелких патчей SystemD и будет она рулить процессами легковесно и надёжно. чего вы в самом деле? (для совсем слепых добавлю тэг #sarcasm)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	85. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:46
	> Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и > то больше шансов. Так если тебе не нравится архитектура - выскажись в рассылке. Предложи архитектуру лучше. Но придется обосновать и на уровне более приличном чем опеннетовский.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Led (ok) on 27-Окт-16, 20:22
	> Будет вам "микро"-ядро от Лёнарта... По сравнению с леннартоподелием любое ядро скоро будет выглядеть "микро".
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:37
	> По сравнению с леннартопoделием любое ядро скоро будет выглядеть "микро". Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	18. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:42
	>> По сравнению с леннартопoделием любое ЗЫ: Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается ))
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	20. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:43
	> Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается )) Нельзя писать "пoделие". А уж леннарто- или линусо- - дело десятое.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:48
	> Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке. Но в ведре количество kloc все равно растет на пару порядков быстрее, чем у системды, так что без шансов.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	88. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:54
	> Но в ведре количество kloc все равно растет на пару порядков быстрее, > чем у системды, так что без шансов. Проклятые железячники пекут железо быстрее чем пирожки. Захочешь не похудеешь. Но если это собрано модулем или не собрано вообще (а зачем тебе на x86 системе поддержка аудио в ARMовской SoC например?) - так этот код у тебя в системе и не присутствует.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	19. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–1 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:42
	> Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз. Fuck you, Security! And you, Stability, too!
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	57. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+3 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 10:05
	> Ну вот, движение к концепции микроядра идёт неизбежно. модуль монолитного ядра (bus1.ko) к микроядрам приближает не больше чем любой другой модуль. Концепция микроядра давно протухла - нет туда никакого движения кроме RTOS для микроконтроллеров да специализированных гипервизоров, все успешные современные коммерческие ОС монолитные. Capability-based IPC и микроядра - это теплое с мягким, просто в UNIX традиционно разграничение прав на уровне пользователей было.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	63. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–2 +/–
	Сообщение от Вареник on 28-Окт-16, 15:16
	Експертное мнение? Ламер, не знающий на чем крутится его смартфон (OKL4/seL4), на чем крутится прошивка любого авто, архитектуру богомерзкой винды (а, это наверное неуспешная ОС) и т.д. :)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	76. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 16:45
	открою вам страшную тайну: в винде ядро тоже монолит
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	86. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:48
	> открою вам страшную тайну: в винде ядро тоже монолит Оно там скорее гибрид, но в целом те же яйца, вид в профиль.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	60. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 12:02
	>Ну вот, движение к концепции микроядра идёт неизбежно. Микроядра взлетят, когда появится аппаратная поддержка для них. Вспомните, после чего начался стремительный взлёт технологий виртуализации? После появления VT-x и AMD-V.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	87. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:49
	> Микроядра взлетят, когда появится аппаратная поддержка для них. Значит это не случится. Memory mapped периферия - наверное не то с чем хотело бы ориентировать микроядро. Потому что подразумевает маппинг периферии в память и прямую (а потому быструю) работу с ней из ядра.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	93. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от decaprox on 01-Ноя-16, 16:51
	MMIO здесь скорее помогает, т.к. позволяет юзерспейс процессам работать напрямую с устройствами. Не со всеми и на на всех платформах, но тем не менее.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	91. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от КО on 31-Окт-16, 12:38
	Так у микроядря требований поменьше, чем у гипервизора. Того, что надо второму первому за глаза. Другое дело, что понаделали костылей - ни тебе вложенности ни параллельной работы. И как после этого запускать гипервизор в микроядре или два рядом?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	77. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:10
	> Ну вот, движение к концепции микроядра идёт неизбежно. Не очень понятно каким боком системная шина связана с микроядром. Системную шину может реализовывать гибрид или монолит. И врядли линукс стал более микроядерным от реализации системной шины (даже не первой). Тем не менее, извращенцы хотящие странного могут - Запилить файлухи в user mode - Запилить драйверы ряда устройств в user mode - Запилить некоторые механизмы в user mode, включая всякие веселости типа user-mode page fault handlers, всякие там BPF VM и прочую работу с пакетами вафли и не только. Но обычно все это не делают, применяя все это только для специфичных случаев.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+2 +/–
Сообщение от Аноним (??) on 27-Окт-16, 19:25
Интересная штука. Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится - проект идет лесом").
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:20
	И как с -ck sheduler. Линус сказал что шедулер должен быть один.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	41. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+4 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:31
	> И как с -ck sheduler. Линус сказал что шедулер должен быть один. Вы про BFS? Лично я в его защиту слышал только про "субъективные ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство, не припоминаю.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	66. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 16:13
	Я про момент, когда CFS ещё не было. Linux 2.6.18, когда-то тогда
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	71. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 29-Окт-16, 01:08
	> Вы про BFS? Лично я в его защиту слышал только про "субъективные > ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство, > не припоминаю. ck - Con Kolivas
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	75. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от KonstantinB (ok) on 30-Окт-16, 12:36
	https://xkcd.com/619/
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	64. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–1 +/–
	Сообщение от Клыкастый (ok) on 28-Окт-16, 15:30
	с Reiser4 там не только автор не нравился. впрочем ZFS это не помешало.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	78. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:14
	> Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится > - проект идет лесом"). Вообще-то в случае kdbus Торвальдс хотел взять в ядро, потому что Кроа-Хартман просил. Но тут Andy Lutomirsky устроил качественный технический разнос. А поскольку он полезный и грамотный коммитер - его мнение сложно не учесть. Ну он и высказал все что думает по поводу принесения всех проблем и грабель dbus. После его отповедей перцы и ушли обратно к drawing board. И сделали сабж. Сам по себе сабж на вид в разы проше и вроде ничем таким не ужасен. Но вот чего я не понимаю так это как будет организован например discovery service'ов в такой топологии и как это будет стандартно, чтобы софт друг друга понимал.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	90. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 03:15
	drawing discovery service boardы
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

4. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–4 +/–
Сообщение от Zenitur (ok) on 27-Окт-16, 19:31
О, уже kdbus закапывают. Значит скоро закопают PulseAudio, Avahi, NetworkManager, PolicyKit и Dbus. А ещё Udisks3 выйдет. Ну а чо? 10 лет уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	49. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от anonymous (??) on 28-Окт-16, 08:11
	>Udisks3 Так уже.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	61. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 14:40
	kdbus зак*пали уже давно. примерно сразу же после того, как стало ясно, что в апстрим не примут.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	72. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 29-Окт-16, 01:10
	любая стабильность — уже застой (по мнению основных движителей никсов)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	79. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:17
	> уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и > может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата? Редхат вообще удоды. Могли бы написать идеальную систему 10 лет назад и всем стало бы хорошо. А они вместо этого какие-то патчи к ядру присылают и деньги стригут. Но ты можешь испортить им бизнес: выпусти идеальную систему, пусть редхат обломается.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	–5 +/–
Сообщение от Crazy Alex (ok) on 27-Окт-16, 19:32
Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается, нужно держать активным своего пира пока не решишь, что все, кто хотел, получили возможность отреагировать на пойманный дескриптор.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Bvz on 27-Окт-16, 19:41
	Тем, что интерпроцесс в юзерленде очень медленный.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 19:51
	И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные - то есть вместо одного обмена сделаем три. Это, конечно, будет много быстрее, чем за раз данные закинуть в ядро.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	29. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 22:50
	> И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные > - то есть вместо одного обмена сделаем три. Это, конечно, будет > много быстрее, чем за раз данные закинуть в ядро. А в случая с сокетами, кидание дескриптора соответствует созданию сокета и подключению к нему. Видимо, сокеты - такой же архитектурный ужас.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	35. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 23:23
	Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	42. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:33
	> Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас. Архитектурное решение в вашем стиле, да. В bus1 тоже на каждое сообщение дескрипторами не обмениваются.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	92. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от КО on 31-Окт-16, 12:41
	Так данные уже в ядре. Этож ЕМНИП внутриядерный обмен.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 19:53
	Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	21. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+2 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:45
	> Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян? В смысле, "нафига делать быстро, если можно меееееедленно"?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	44. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:38
	> Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян? Следующий шаг в рамках такой логики - создать специальный супермедленный IPC, чтобы учить пользователей смирению и прививать им любовь к апгрейдам.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	22. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:48
	> Тем, что интерпроцесс в юзерленде очень медленный. Ну да, обязательно нужна возможность погонять через IPC HD-pr0n, куда же без этого! Всякие zero-copy навороты  -- немолодежное старье!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	50. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от anonymous (??) on 28-Окт-16, 08:12
	> Тем, что интерпроцесс в юзерленде очень медленный. И за счёт чего его собрались ускорять, пихая в ядро?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	80. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:24
	> И за счёт чего его собрались ускорять, пихая в ядро? За счет отсутствия переключений контекста, например. Линуксное ядро на эту тему вообще активно развивали - оно IIRC при сильной нагрузке аж сисколы группирует и перекидывает данные между режимами сразу батчами. Чтобы поменьше контексты переключать.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	17. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:41
	> Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не > угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается, > нужно держать активным своего пира пока не решишь, что все, кто > хотел, получили возможность отреагировать на пойманный дескриптор. И как на этом сделать подписку на определенные события? А мультикаст? (Ответ "не нужно" не катит, это всего лишь индикатор мизерного программистского опыта отвечающего)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	31. "Для ядра Linux вместо kdbus предложена новая шина обмена соо..."	+/–
	Сообщение от Crazy Alex (ok) on 27-Окт-16, 22:54
	Ровно так же, как и с этой штукой - данная часть не будет отличаться, по идее. Более того - эмуляция предлагаемого безумного режима делалась бы тривиально - просто сообщение маркировалось бы как имеющее "расширенное тело" и ID, по которому можно это самое тело запросить.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

11. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
Сообщение от Аноним (??) on 27-Окт-16, 20:00
Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из юзерспейса решат все проблемы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:35
	Фатальную Проблему она не решает.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:37
	> Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из > юзерспейса решат все проблемы. А как на этом сделать мультикаст?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	25. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	–1 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 21:55
	> мультикаст Перебрать всех известных клиентов в цикле и не загромождать API ядра. Клиентов максимум пару сотен будет (а реально штук 10-20).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	28. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+2 +/–
	Сообщение от Аноним (??) on 27-Окт-16, 22:49
	> Перебрать всех известных клиентов в цикле и не загромождать API ядра. А если список клиентов заранее неизвестен? Примеры: подписки на события типа "смена часового пояса" (важно всем программам, работающим с локальным временем), "поднятие сетевого интерфейса" и т.д.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	38. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 00:03
	> А если список клиентов заранее неизвестен? Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но можно отправить всем сразу одним вызовом. ИМХО, мультикаст на уровне ядра может оптимизировать только количество переключений контекста "ядро<->юзерспейс" (т.к. цикл будет гонять ядро в одном системном вызове). Может быть, получится снизить количество копирований мультикаст-сообщения (не уверен, тут надо глубоко вникать). Для сообщений уровня "вставлена флешка" и "переход на питание от батареи" пофиг на оверхед.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	40. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:27
	> Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу > отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но > можно отправить всем сразу одним вызовом. Каждому по отдельности? It's super effective! // Из-за таких "эффективных программистов" вроде бы простые приложения еле ворочаются на современной технике, хотя по функциональности они недалеко ушли от софта времен 80386.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	46. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 02:28
	О, сразу про "эффективных программистов" вспомнил. Ничего, что Линус в прошлый раз завернул эту компашку с резолюцией "у вас неэффективное гoвнo в юзерспейсе, перепишите там, потом приходите в ядро"?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	81. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:27
	> О, сразу про "эффективных программистов" вспомнил. А если про них не вспоминать - так dbus уже есть. Да и binder с другой стороны. Поэтому изобретать что-то новое имеет смысл если видится возможность что-то улучшить.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	52. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 09:00
	> Каждому по отдельности? It's super effective! Не придирайся. "броадкаст неизвестному количеству клиентов" вообще плохо сочетается с требованием "гарантированной доставки". Поэтому циклы придется гонять в любом случае, вопрос только кому именно...
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	67. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Elhana (ok) on 28-Окт-16, 17:51
	Так судя по их презентации оно и отправляет этот "мультикаст" именно каждому пиру в отдельности, просто делает это так, что все получат его "одновременно", чтобы гарантировать очередность доставки - это какой-то достаточно специфический сценарий, который видимо только редхату и нужен и который они позиционируют как фатальный недостаток всех других ipc.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	33. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 23:10
	есть netlink который умеет и multicast тоже.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	43. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:36
	> есть netlink который умеет и multicast тоже. А можно пример проги, которая использует netlink и запускается не от рута, а от юзера?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	62. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 14:45
	>> есть netlink который умеет и multicast тоже. > А можно пример проги, которая использует netlink и запускается не от рута, > а от юзера? iproute2
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	65. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 16:00
	мультикаст в netlink можно только от рута использовать
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	82. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:28
	> А можно пример проги, которая использует netlink и запускается не от рута, а от юзера? iw например.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

26. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+1 +/–
Сообщение от freehck (ok) on 27-Окт-16, 22:20
Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же разговоры идут. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+2 +/–
	Сообщение от freehck (ok) on 27-Окт-16, 22:29
	Ну точно: 17 августа. http://lwn.net/Articles/697191/
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	32. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 27-Окт-16, 22:59
	> Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же > разговоры идут. :) Насколько я помню, еще с начала года.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	56. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Окт-16, 10:04
	>> Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же Эта новость наверху -- отдельная невиданная доселе веха, "новый" код явлен Миру. Ларабель Похорониксович празднует. Ждём длиииинной череды постов про "Кернел N+0.1: BUS1 снова-опять-почему-то-ждём-скучаем не в мейнлайне" от задорного парня Микаэля. >> разговоры идут. :) > Насколько я помню, еще с начала года. Сначала их долго выпинывали, наконец до них дошло... Но не совсем: они почему-то решили, что нарисовать с нуля и сменить вывеску "должно всё изменить"ТМ. Придумали название и пошли писать код. 09.12.2015 BUS1: A New Linux Kernel IPC Bus Being Made By Systemd Developers   http://www.phoronix.com/scan.php?page=news_item&px=BUS1-In-D... 09.11.2015 KDBUS Is Indeed Going Back To The Drawing Board   http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Bac... 30.10.2015 KDBUS Is Being Removed From Fedora, Could Be A While Before Being Mainlined   http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Dr... 10.07.2015 The NSA Is Looking At Systemd's KDBUS   http://www.phoronix.com/scan.php?page=news_item&px=NSA-KDBUS...
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	59. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от freehck (ok) on 28-Окт-16, 11:33
	> A New Linux Kernel IPC Bus Being Made By Systemd Developers Погодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	83. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	–2 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:32
	> Погодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк. Да, эти ребята не только сделают шину но ей еще и софт сможет реально пользоваться. А не как у других ребят - какая-то номинальная куита для галочки, которой может и не быть в 80% систем, так что вы там держитесь и кодьте покамест fallback сами. Что вам, впадлу самому системную шину реализовать как умеете?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

36. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	–1 +/–
Сообщение от Аноним (??) on 27-Окт-16, 23:54
самое интересное: надеюсь протокол - текстовый?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+3 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 02:29
	Каанешно! :-) http://gentooexperimental.org/~patrick/weblog/archives/2014-...
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

37. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
Сообщение от anonymous (??) on 27-Окт-16, 23:58
ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию пОТТЕРА! а в идеале за недельку сам напишет человеческий аналог который везде продвинут
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 01:43
	> ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку пoделию пОТТЕРА! Он уже это сделал > I don't personally mind systemd, and in fact my main desktop and laptop both run it © Linus
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	48. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 28-Окт-16, 03:04
	Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера, а с другой - ты акционер Red Hat. И как вот выкручиваться от таких вопросов ребром?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	73. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 29-Окт-16, 01:15
	> Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной > стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера, > а с другой - ты акционер Red Hat. И как вот > выкручиваться от таких вопросов ребром? крупный акционер имеет веский голос в принятии решений или нет? сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется значит, его все и так устраивает
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	74. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Аноним (??) on 29-Окт-16, 01:43
	Похоже, что он вовсе не такой крупный, как вам кажется. https://investors.redhat.com/stock-information/ownership-pro... В любом случае, дело-то не в том, крупный ли он акционер, а в том, что он медийная личность, и неаккуратно проболтавшись о технической стороне вопроса он может сильно нагреть самого себя прежде всего. >сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется Они-то как раз все понимают. Леня им сотворил гигантский зонд, который по сути вендорлочит вообще все линукс-коммьюнити на ред хате. А раз оно формально free software, то вроде бы и не придерешься.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	84. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 01:36
	> Это он дипломатично увернулся от неудобного вопроса. Это скорее хейтеры демонстрируют wishful thinking во весь рост. А так Торвальдс может без обиняков заявить Каю Сиверсу (или любому другому) что тот full of sh*t если тот косячит. С предложением вытряхнуть sh*t и прийти в адекват. А кто сказал что Сиверс или там кто еще на это не способны? Судя по кардинальной переделке сабжа - вполне себе.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	54. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Окт-16, 09:20
	> ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию > пОТТЕРА! > а в идеале за недельку сам напишет человеческий аналог который везде продвинут Ты всё перепутал: там, когда было переписывание за недельку, Линусу не давали пользоать, но дали "списать", а тут всё наоборот: пользование пхают во все дыры, а от "списывания" он "диполоматично уварачивается"ц, аотому как нет там :/ предмета для творческой кражи. Совсем не похоже.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

53. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	–2 +/–
Сообщение от darkshvein (ok) on 28-Окт-16, 09:15
попетросяню. systemdBus1 ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Окт-16, 10:22
	> попетросяню. systemdBus1 ? Нет, s-d-libkerneld. Всё остальное ядро будет пришлёпкой сбоку к Великому Поделию. Щупальца №2, ну, бишь bus1, запускается, запускается щупальца... в ядро...
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

55. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
Сообщение от Нанобот (ok) on 28-Окт-16, 09:48
>сокрытие информации ст 237 УК РФ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

94. "Для ядра Linux вместо kdbus предложен механизм межпроцессных..."	+/–
Сообщение от Аноним (??) on 13-Май-17, 20:58
Ох, жарко то как, аж криокамера у меня поломалась! Ну заменят допустим kdbus на bus1, но самый обычный DBus никуда не денется-то... если вдруг даже на десктопе и нужен будет DBus с ядерной скоростью, то напишут для отдельных просителей и ответчиков обёртку типа apulse и xwayland, и libdbus для LD_PRELOAD Совместимость древнего и заброшенного поломается не сильно, зато можно будет сочетать безопасность со скоростью.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема