LINUX.ORG.RU
ФорумTalks

Нарисовался срачик при попытке мерджа kdbus в ядро

 , ,


0

1

Just to recap how it went the last time around: Kay kept pushing his piece of code into the tree, claiming that it was optional, that nobody who doesn't like it has to enable it, so what's the problem? OK, in it went. And pretty soon udev (maintained by the same... meticulously honorable person) had stopped working on the kernels that didn't have that enabled.

We had been there before. To paraphrase another... meticulously honorable person, «if you didn't want something relied upon, why have you put it into the kernel?» Said person is on the record as having no problem whatsoever with adding dependencies to the bottom of userland stack.

IMO either it's OK without «if you don't like it, don't enable it», or it should not be merged at all.

https://lkml.org/lkml/2015/4/13/712

upd: да там дальше по тексту настоящая схватка

★★★★★

Грег за друзиков из RH обиделся?

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

офтопъ

качественный и холиварный вброс это один из пунктов ЛОРовского чеклиста для каждого пятизвездочного^W пользователя

ZuBB ★★★★★ ()

добавлю ка я

From One Thousand Gnomes <> Subject Re: [GIT PULL] kdbus for 4.1-rc1

Look, us kernel developers only work on one huge, multithreaded, global
state binary. Our experience in multi-application interactions with
shared state and permission requirements is usually quite limited. If
you don't trust the developers of those programs outside the kernel,
don't use them, there are still distros out there that don't require
them.

Speak for yourself. There are a lot of us here who work and have worked on low level messaging, on networking, on clusters and on things like distributed shared memory, infiniband etc. I've worked on networks, including broken stateful protocols, I've maintined and developed internet and ISDN router code, I've worked with message passing realtime systems.

Equally the folks who wrote dbus generally also know sweet fa about writing a kernel and maintaining it for 25 years. Gtk is on its 3rd completely incompatible instance (and has incompatibilities even within major versions), Gnome is on its third major incompatible release - closer would be to say at least the «second project with the same name», and neither are as old as the kernel.

dbus is not an appropriate design for a kernel messaging layer for a variety of reasons. That's not to say dbus shouldn't be able to use a fast kernel messaging layer, or that one shouldn't exist.

dbus is basically a very large very specialized and somewhat flawed policy engine on top of what should be simple messaging. The two need splitting apart.

Abstract low level messaging layers are not a new concept. V7 unix had one experimentally. It's about getting the separation right.

IMHO that probably involves getting the right people in the right place together - dbus designers, MPI and realtime people, kernel folks and possibly also some of the hardware messaging folk.

In filesystem terms

- stop writing a dbus only file system - figure out what a messaging «vfs» looks like - figure out what an clean low level kernel model looks like - figure out what has to be where to put the policy in userspace

What might also be worth review is how much dbus traffic actually ought to be an object store implemented say with tmpfs and inotify type functionality (or extensions of that) so that you can set/read/enumerate/get change notifications on properties.

Alan

ZuBB ★★★★★ ()

Да, там каждый раз такое случается. Приходит Грег, постит свой шлак. Через пару недель в тред забредает Энди и говорит «Чуваки, тут дыра, тут дыра и тут дыра в дизайне. Зачем это вообще нужно?». Вылезает Грег и начинает орать, что это быстро, модно и молодежно. Приходит Эрик и поддерживает Энди. Грег начинает истерить, что его никто не любит. Приходит Виро и говорит, что там ещё больше дыр, чем думал Энди и вообще выглядит как эталонное ненужно. Потом Грег правит минорные проблемы и итерация повторяется.

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

спс за краткий пересказ последних Х серий (серьезно).

Я почитал дискусию 2х итераций и мне показалось что Грег заинтересован в качественной реализации..

ZuBB ★★★★★ ()
Последнее исправление: ZuBB (всего исправлений: 1)
Ответ на: комментарий от ZuBB

То ли Энди, то ли ещё кто-то писал хороший пост о том, что попытка засунуть kdbus выглядит как DOS. Чуваки постят код, правят минорные баги, постят код, правят минорные баги... Пока обсуждающим не надоест каждый раз говорить одно и то же и они не махнут рукой. Но в этот раз все уперлись и пошли на принцип.

kirk_johnson ★☆ ()

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

И очень много всякой херни не по теме, у Грега идеальное терпение, был бы это Линус - весь lkml бы матом покрылся.

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

Грег об этом каждый раз заявляется. А потом кто-нибудь в очередной раз тыкает Грега носом в метаданные к каждому пакету и связанные с этим проблемы безопасности.

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

Многохурдие

Не уверен обновили ли уже Дебиан, но скоро должны...

Погодите, их много что ли? Есть какой-то GNU/Hurd который не Debian? Arch, насколько я знаю, уже мёртв. Guix ещё не грузится (сегодня письмо от Phant0mas'а получил, к концу лета рассчитывает, что будет грузится).

Camel ★★★★★ ()
Ответ на: Многохурдие от Camel

Hurd это ядро.
GNU это «обязка». Утилиты, скрипты и прочая дребедень.
Debian это дистрибутив.

Debian GNU/Hurd — Дебиан дистр на базе Hurd.

Для аналогии:

Linux это ядро.
GNU это «обязка». Утилиты, скрипты и прочая дребедень.
Debian это дистрибутив.

Debian GNU/Linux — Дебиан дистр на базе линукса.

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

GNU HURD != GNU/HURD

Hurd это ядро.

Всё ещё запутаннее. Ядро — GNU HURD, операционка — GNU/HURD.

Похоже версия 0.6 относится именно к ядру, которое GNU HURD.

Camel ★★★★★ ()
Ответ на: We need to go deeper от Camel

Hurd это комплекс из микроядра-диспетчера и множества демонов. Но в сумме они все представляют из себя то, что нынче принято называть ядром.

Stahl ★★☆ ()
Ответ на: GNU HURD != GNU/HURD от Camel

Не угадал. Ядро GNU Mach. GNU HURD это набор сервисов вокруг ядра. HURD (гну через слеш не пишется, так как хурд и так часть гну) это система.

kim-roader ★★ ()
Ответ на: комментарий от Lavos

как ты угадал?!!

I don't understand. You can not like the D-Bus model (and accordingly
the X11 model),

I thought that the general hatred level of the X11 «model» and the protocol lead to al the efforts to reimplement this properly ... in userspace (for example Wayland, right?).

I don't think anyone was ever seriously suggesting «X11 model is broken, so let's push it to kernel» ... ?

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

как ты угадал?!!

Ну если бы я сидел на мете, меня бы такие же мысли посещали.

Lavos ★★★★★ ()

да там дальше по тексту настоящая схватка

в основном припоминают предыдущие заслуги системдевщиков на ниве ломания ведра своими костылями.

дальше не читал.

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

Судя по аргументации Грега - да:

Yes, it's an unfortunate design, but one that we are all stuck with

Энди в ответ:

I agree. You've sent a pull request for an unfortunate design. I don't think that unfortunate design belongs in the kernel. If it says in userspace, then user programmers could potentially fix it some day.

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

Пока похоже на то, основные ревьюеры кода отказываются дать ему зелёный свет.

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

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

Да, Грег жжот напалмом. Любопытно то, что он до сих пор (уже полгода где-то) не может привести пример того, где скорость kdbus (с которой тоже не все гладко) была бы полезна IRL.

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

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

Too fat.

tailgunner ★★★★★ ()

Так всем известно, что сладкая парочка Кей+Леннарт - криворукие долбодятлы.

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

Грег тоже упоролся, да. Вот тот же гугль свой binder сделал и ничего - живы-здоровы.

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

Пока похоже на то, что основные ревьюверы кода отказываются его ревьюировать ссылаясь на сложность и размер

Ну да, Alan об этом писал. И тащем-то он прав: если у чуваков с их опытом разработки ядра возникают сложности с пониманием кода в патче, то код в патче сильно переусложнен и в ядре такому делать нечего.

kirk_johnson ★☆ ()

Воот! А когда я говорил, что и в третий раз Грега и Ко завернут с kdbus'ом, мне говорили что это все ГКей Сиверс его тащил.

Meyer ★★★★ ()

Да, я уже читаю с попкорном. TL;DR: Пока kdbus не готов еще, большой оверхед, многое сделано странно.

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

TL;DR: Пока kdbus не готов еще, большой оверхед, многое сделано странно.

Хм. Вообще-то прямо сказано «всё это говно в ядре не нужно, а нужна быстрая система локального IPC, над которым можно построить и D-Bus, и MPI, и QNX».

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

Что переводится как «не готов», в том числе архитектурно. В ядро это дело рано или поздно в каком-то виде пропихнут, но уж точно не сегодня.

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