Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kdbus in the kernel
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
gwr
n00b
n00b


Joined: 19 Nov 2014
Posts: 12

PostPosted: Thu Nov 20, 2014 2:05 pm    Post subject: kdbus in the kernel Reply with quote

I'm trying to learn about the technical reasons for kdbus and I have a few noob-type questions that maybe someone here can help me with.

I have gone all the way back in time to this blog posting:
http://blogs.gnome.org/rodrigo/2012/02/27/d-bus-optimizations/

It seems like the two main candidates (shared mem and multicast IPC were ignored because of the amount of work involved, not due to technical reasons:

"was a (maybe) good idea, as it would mean peers in the bus would use shared memory segments to send messages to each other. But this would mean mostly a rewrite of most of the current D-Bus code"

"but this seems to be too much overhead for the D-Bus"

The only slightly technical item I read was:

"as we would have to use eth0 or similar, as multicast on loopback device doesn’t exist (hence no D-Bus in computers without a network card). Also, losing packets is another caveat of this solution, as well as message order guarantee"

But wouldn't this whole thing have been easier if someone added multicast to the loopback? Is there a technical reason why that couldn't have been done rather that shoving an entirely new bus into the kernel?

Thanks!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2475
Location: Dallas area

PostPosted: Fri Nov 21, 2014 3:36 pm    Post subject: Reply with quote

PATCH v2 00/13 http://lkml.iu.edu/hypermail/linux/kernel/1411.2/index.html search on kdbus

No comments from the kernel devs yet on version #2.

Edit to add: just saw some comments, and they still haven't got it clean enough (code wise) to get an ack on getting any further than they are now.
But it's interesting to watch.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2010)
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2475
Location: Dallas area

PostPosted: Sat Nov 22, 2014 1:26 pm    Post subject: Reply with quote

http://lkml.iu.edu/hypermail/linux/kernel/1411.2/04920.html

All your kdbus are belong to us! :lol:


And some of these "devs" wonder why Linus discouraged them from thinking that they could ever be kernel devs.

Edit to add: Security, clean well understood functions, good design are not just bolt-ons "to be done later" in revision #whatever
They are intrinsic to the whole.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2010)
Back to top
View user's profile Send private message
gwr
n00b
n00b


Joined: 19 Nov 2014
Posts: 12

PostPosted: Mon Nov 24, 2014 12:09 am    Post subject: Reply with quote

Thnks for the links, they help a lot. I am no security expert, but is the claim that the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?

Last edited by gwr on Mon Nov 24, 2014 11:36 am; edited 1 time in total
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 644

PostPosted: Mon Nov 24, 2014 12:25 am    Post subject: Reply with quote

gwr wrote:
Thnks for the links, they help a lot. I am no security expert, but is the claim thst the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?


This is where gentoo has it's strength.
Don't like the that kernel component? Don't select it and it won't compile.
It's what i do with SElinux. I just can't trust it due it's CIA backing.
_________________
"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
—Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Wed Nov 26, 2014 10:23 am    Post subject: Reply with quote

gwr wrote:
Thnks for the links, they help a lot. I am no security expert, but is the claim that the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?

Not really. In any event it's just hand-waving to give a pretext, that hopefully no-one will argue with, mainly because anyone who knows it's rubbish is likely already against kdbus, and can't be bothered to get involved with the argument. Anyone who's not sure is a target of the propaganda campaign, and this is just part of the generalised FUD.

In this case, uncertainty leads to doubt of who's right, and (explicitly-invoked) fear that without kdbus, one is leaving one's system open to abuse. OFC the possibility of not having any sort of dbus at a system-wide level (as it's reimplementing the kernel) is never entertained.

The hand-waving aspect is the conflation of trustworthy (with connotations of trustworthy computing) with file-system permissions and intrusion-detection systems. kdbus has absolutely nothing to do with that discussion.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2475
Location: Dallas area

PostPosted: Wed Nov 26, 2014 8:03 pm    Post subject: Reply with quote

And the battle continues :lol:

Fortunately Andy L isn't letting them put whatever they want into the kdbus code, they're having to justify much of it.

Edit to add: I get the impression that the sysd people thought that they could waltz in
and shove slightly modified dbus code into the kernel, warts and all.
Glad to see they're being called on their assumption.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2010)
Back to top
View user's profile Send private message
ct85711
Apprentice
Apprentice


Joined: 27 Sep 2005
Posts: 153

PostPosted: Wed Nov 26, 2014 8:59 pm    Post subject: Reply with quote

The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work.
Back to top
View user's profile Send private message
The Doctor
Veteran
Veteran


Joined: 27 Jul 2010
Posts: 1524

PostPosted: Wed Nov 26, 2014 9:04 pm    Post subject: Reply with quote

ct85711 wrote:
The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work.


No, the real show is when the kernel devs refuse patches that break things "just because."
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2477
Location: Austria

PostPosted: Wed Nov 26, 2014 9:23 pm    Post subject: Reply with quote

Anon-E-moose wrote:
And the battle continues :lol:

Fortunately Andy L isn't letting them put whatever they want into the kdbus code, they're having to justify much of it.

It's quite amusing, but well, isn't that what review is for?

kdbus gets beaten until it is in shape, I'm sure it won't make it into the kernel anywhere near 3.19, 3.20.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2475
Location: Dallas area

PostPosted: Wed Nov 26, 2014 10:26 pm    Post subject: Reply with quote

The Doctor wrote:
ct85711 wrote:
The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work.


No, the real show is when the kernel devs refuse patches that break things "just because."


++
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2010)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Fri Nov 28, 2014 11:13 am    Post subject: Reply with quote

It's a shame the kernel devs can't really question the use-case for all this. As imo the whole kdbus thing should never even get into the kernel, and wouldn't if kernel folks were looking at the whole picture, including userland application from the top down.

ATM it's somehow "been accepted" that "RPC" is a valid thing to be doing in a local-machine context.

For the avoidance of doubt: it's not. It's completely insane, and is part of what makes me feel we've gone through the looking-glass.

It would be much more honest and to the point, to talk about an ORB which is basically what dcop was about. Incidentally dcop was a much better solution, and already easily-scriptable for humans.

Instead of saying "dbus does everything dcop does, let's use it," the position should have been "dcop does everything we need, and is much cleaner, let's use it, and maybe extend it."

I had no position on the above when it happened; I loved dcop in KDE-3.5.x and was mighty disappointed when Kommander/Kaptain (can't remember which it was) was not present in 4.x. I assumed that "since dbus is a superset of dcop" it would soon arrive, but it never did through the whole of KDE-4. Which just told me at least, that dbus is inferior.

A quick perusal of the uses of dbus, as opposed to how dcop was put together, merely confirmed that a much-less capable design-team were in charge (and loving being in charge).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum