Off-topic: D-Bus in the kernel

Just spotted this interesting post about putting d-bus in the kernel [
http://alban.apinc.org/blog/2010/09/15/d-bus-... ]

Fascinating work.

====
September 15, 2010
D-Bus in the kernel, faster!
Filed under: General, Hacking, Informatique, maemo — alban @ 4:03 pm

In the last few weeks, I worked on having D-Bus directly in the Linux
kernel to improve its performances. I based my work on what Ian Molton
did. For now it’s just a prototype, but some benchmarks I did show a
good performance improvement.

[...]

The first benchmark is dbus-ping-pong. It is a simple tool to call a
D-Bus method and wait for the reply 10000 times. I tried it both on a
KVM/i386 virtual machine and on a N900/arm.

    * KVM/i386, without kdbus: 3.887s
    * KVM/i386, with kdbus: 2.085s (x1.8)
    * N900/arm, without kdbus: 28.00s
    * N900/arm, with kdbus: 9.23s (x3)

[...]
====-- 
Soh Kam Yung
my Google Reader Shared links:
(http://www.google.com/reader/shared/168518151...)
my Google Reader Shared SFAS links:
(http://www.google.com/reader/shared/user/1685...)

Hello,On Thursday 16 September 2010, Soh Kam Yung wrote:
> Just spotted this interesting post about putting d-bus in the kernel [
> http://alban.apinc.org/blog/2010/09/15/d-bus-... ]Unfortunately, the D-Bus bus is too feature-bloated to be implemented in 
kernel. For one thing, routing messages will be no fun, the kernel would have 
to parse and keep track of the AddMatch requests. Arguably, a kernel-space D-
Bus should implement signal subscription out-of-band (compare to the IP 
multicast ioctl()s). But then it's not really the D-Bus protocol anymore.

Feature negotiation will also make a kernel implementation more difficult. It 
means more messages to parse and more state to keep in kernel.

But I expect the worst part of a kernel D-Bus to be the security enforcement. 
Parsing files in kernel space is a complete non-starter, and that includes 
service files. So it might be possible to move the session bus to kernel space, 
but I am not very optimistic about the system bus. Hmm, anyone for dbustables 
and NetFilter-DBus?


Also, this article contains some highly suspicious inaccuracies. skb_clone() 
does not copy message buffers, only buffer heads.-- 
Rémi Denis-Courmont
http://www.remlab.net/

Le Thu, 16 Sep 2010 07:37:33 +0300,
"Rémi Denis-Courmont"  a écrit :

>    Hello,
> 
> On Thursday 16 September 2010, Soh Kam Yung wrote:
> > Just spotted this interesting post about putting d-bus in the
> > kernel
> > [ http://alban.apinc.org/blog/2010/09/15/d-bus-... ]
> 
> Unfortunately, the D-Bus bus is too feature-bloated to be implemented
> in kernel. For one thing, routing messages will be no fun, the kernel
> would have to parse and keep track of the AddMatch requests.It is not conditional or future: the prototype does parse match rules
in the kernel and keep track of them with very similar data structures
to dbus-daemon (but using rb tree and lists from the kernel instead of
DBusHash and DBusList).> Arguably, a kernel-space D- Bus should implement signal subscription
> out-of-band (compare to the IP multicast ioctl()s). But then it's not
> really the D-Bus protocol anymore.I kept the same D-Bus protocol in the prototype.> Feature negotiation will also make a kernel implementation more
> difficult. It means more messages to parse and more state to keep in
> kernel.Which feature negotiation do you refer to?> But I expect the worst part of a kernel D-Bus to be the security
> enforcement. Parsing files in kernel space is a complete non-starter,
> and that includes service files. So it might be possible to move the
> session bus to kernel space, but I am not very optimistic about the
> system bus. Hmm, anyone for dbustables and NetFilter-DBus?Indeed. Nothing is decided for the security policy. There are still
design choices to do! Looking into NetFilter is my next step.> Also, this article contains some highly suspicious inaccuracies.
> skb_clone() does not copy message buffers, only buffer heads.I didn't say skb_clone copies the message buffers but the opposite
actually: the message buffer is copied exactly one time and the buffer
heads are copied as many time as there is recipients by using
skb_clone().

My first version did copy the buffers several times, but then I
understood how to use skb_clone() correctly and fixed it.

Is there other inaccuracies or something unclear?-- 
Alban

Hi Remi,> > Just spotted this interesting post about putting d-bus in the kernel [
> > http://alban.apinc.org/blog/2010/09/15/d-bus-... ]
> 
> Unfortunately, the D-Bus bus is too feature-bloated to be implemented in 
> kernel. For one thing, routing messages will be no fun, the kernel would have 
> to parse and keep track of the AddMatch requests. Arguably, a kernel-space D-
> Bus should implement signal subscription out-of-band (compare to the IP 
> multicast ioctl()s). But then it's not really the D-Bus protocol anymore.not sure how you come to your conclusion. D-Bus is a well defined
inter-process/networking protocol and so it does make sense to implement
it in kernel space. For the signal subscription via AddMatch, there
might is some extra work needed, but surely that is not argument to not
try it.> Feature negotiation will also make a kernel implementation more difficult. It 
> means more messages to parse and more state to keep in kernel.Feature negotiation is done once when connecting to the bus. And it is
not using D-Bus message at all. You might wanna re-read on the feature
negotiation and authentication pieces in the D-Bus protocol.> But I expect the worst part of a kernel D-Bus to be the security enforcement. 
> Parsing files in kernel space is a complete non-starter, and that includes 
> service files. So it might be possible to move the session bus to kernel space, 
> but I am not very optimistic about the system bus. Hmm, anyone for dbustables 
> and NetFilter-DBus?I don't see this as a problem. Of course nobody is parsing XML files
inside the kernel, but then again, the whole security of D-Bus should be
deprecated anyway. The only security handling needed is for the owner of
the bus name for the system bus. Access to D-Bus API should not be done
by a static security policy. Using dynamic policies via PolicyKit or
something similar is a way better approach anyway.

And besides that you can just label D-Bus interfaces with SELinux or LSM
specific contexts like D-Bus already does these days. Then it is only up
to load the specific SELinux or LSM policy. Seems to be me pretty
generic and fits well into the current security framework.

Regards

Marcel

On Fri, 17 Sep 2010 08:18:00 +0900, Marcel Holtmann 
wrote:
> not sure how you come to your conclusion. D-Bus is a well defined
> inter-process/networking protocol and so it does make sense to implement
> it in kernel space.Sure.> For the signal subscription via AddMatch, there
> might is some extra work needed, but surely that is not argument to not
> try it.You don't (selectively) parse HTTP headers in the TCP/IP stack, do you?.
AddMatch, and in fact, any (in-band) request to the bus will require
parsing whole DBus messages in kernel space - or offloading to a user-space
bus helper that instructs the kernel via some funky ioctl()s or similar.>> But I expect the worst part of a kernel D-Bus to be the security
>> enforcement. Parsing files in kernel space is a complete non-starter,
>> and that includes service files. So it might be possible to move the
>> session bus to kernel space, but I am not very optimistic about the
>> system bus. Hmm, anyone fordbustables and NetFilter-DBus?
> 
> I don't see this as a problem. Of course nobody is parsing XML files
> inside the kernel, but then again, the whole security of D-Bus should be
> deprecated anyway.That might be a good idea. But will this fly with the community at large?
Kernel DBus might be a tough sell if it removes well-established
"features".-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

Hi Remi,> > not sure how you come to your conclusion. D-Bus is a well defined
> > inter-process/networking protocol and so it does make sense to implement
> > it in kernel space.
> 
> Sure.
> 
> > For the signal subscription via AddMatch, there
> > might is some extra work needed, but surely that is not argument to not
> > try it.
> 
> You don't (selectively) parse HTTP headers in the TCP/IP stack, do you?.
> AddMatch, and in fact, any (in-band) request to the bus will require
> parsing whole DBus messages in kernel space - or offloading to a user-space
> bus helper that instructs the kernel via some funky ioctl()s or similar.we could use the socket filter actually for this. We have used that
nicely with udev and might work out here as well. Or some modified
version that does the matching. In the end D-Bus is a well-defined
binary protocol with a bunch of strings.> >> But I expect the worst part of a kernel D-Bus to be the security
> >> enforcement. Parsing files in kernel space is a complete non-starter,
> >> and that includes service files. So it might be possible to move the
> >> session bus to kernel space, but I am not very optimistic about the
> >> system bus. Hmm, anyone fordbustables and NetFilter-DBus?
> > 
> > I don't see this as a problem. Of course nobody is parsing XML files
> > inside the kernel, but then again, the whole security of D-Bus should be
> > deprecated anyway.
> 
> That might be a good idea. But will this fly with the community at large?
> Kernel DBus might be a tough sell if it removes well-established
> "features".I don't really call this a well-established feature. The security policy
file has been a problem for quite some time. It is not flexible enough.
And if you look at the installed policy files for your desktop Linux
system right now. You don't see much use of it anyway. Just the bus name
owner section is important. The rest is kind either allowed by default
or rejected by default. And the at_console part has been proven to be
pretty hard in reality. Hence a bunch of applications just rely on
PolicyKit instead D-Bus security policy.

Regards

Marcel

This really needs a conformance suite (or at least basic test suite)
for dbus-daemon. IMHO writing any variant of the daemon without a test
suite is essentially crazy. The spec does not really cover the
daemon's behavior in sufficient detail, and there are a whole lot of
details. line-by-line the code needs converting to spec and/or tests.

Havoc

Hi Havoc,> This really needs a conformance suite (or at least basic test suite)
> for dbus-daemon. IMHO writing any variant of the daemon without a test
> suite is essentially crazy. The spec does not really cover the
> daemon's behavior in sufficient detail, and there are a whole lot of
> details. line-by-line the code needs converting to spec and/or tests.and while at it, we need a fuzzing tool for D-Bus. I meant to write one
since a long time, but never got enough time for it. If anybody is
looking for a hobby project, here is an idea ;)

Regards

Marcel

Em Sexta-feira 17 Setembro 2010, às 10:32:26, Marcel Holtmann escreveu:
> Hi Havoc,
> 
> > This really needs a conformance suite (or at least basic test suite)
> > for dbus-daemon. IMHO writing any variant of the daemon without a test
> > suite is essentially crazy. The spec does not really cover the
> > daemon's behavior in sufficient detail, and there are a whole lot of
> > details. line-by-line the code needs converting to spec and/or tests.
> 
> and while at it, we need a fuzzing tool for D-Bus. I meant to write one
> since a long time, but never got enough time for it. If anybody is
> looking for a hobby project, here is an idea ;)What do you mean by a fuzzing tool?

Hi Thiago,> > > This really needs a conformance suite (or at least basic test suite)
> > > for dbus-daemon. IMHO writing any variant of the daemon without a test
> > > suite is essentially crazy. The spec does not really cover the
> > > daemon's behavior in sufficient detail, and there are a whole lot of
> > > details. line-by-line the code needs converting to spec and/or tests.
> > 
> > and while at it, we need a fuzzing tool for D-Bus. I meant to write one
> > since a long time, but never got enough time for it. If anybody is
> > looking for a hobby project, here is an idea ;)
> 
> What do you mean by a fuzzing tool?I mean a proper fuzzing tool that can be used to check D-Bus server
implementations. Same as you would fuzz network protocols.

Regards

Marcel

I have 2 questions:

Anyone have tried performance improvements other than a simple ping-pong ?
Are we speaking about putting DBus in kernel by rethinking it's design
and how it can be divided to kernelSpace + userSpace components ?

Le Fri, 17 Sep 2010 16:04:55 +0200,
Mohamed Ikbel Boulabiar  a écrit :

> I have 2 questions:
> 
> Anyone have tried performance improvements other than a simple
> ping-pong ?Hi,

I tested 3 performance tests and I listed them there:
http://alban.apinc.org/blog/2010/09/15/d-bus-...

I chose the ping-pong because this use-case shows the better
performance improvements.

I also chose the Jabber connection on the N900 with Telepathy because it
is an user-oriented test and it generates a lot of D-Bus traffic between
the connection manager, the address book, the widgets on the desktop.

If you have an idea of sensible test, I can give it a try.> Are we speaking about putting DBus in kernel by
> rethinking it's design and how it can be divided to kernelSpace +
> userSpace components ?The protocol and semantic from the applications point of view didn't
change. It is just a new kind of socket supported, in addition to the
existing support for Unix sockets and TCP sockets. I think it is
important that no changes are required in applications. Only a small
patch in libdbus (6 files changed, 333 insertions(+), 1 deletions(-)).

The support for Unix/TCP sockets is not removed and will not be
deprecated: it will still be needed on non-Linux platforms and peer to
peer connections at least. dbus-daemon listens on AF_DBUS socket only
if the configuration file says so with <listen/>.


How to divide between kernel space and user space is a good question
and it is not decided. Here are my thoughts about the division and how
it is currently implemented in the kdbus prototype:

- Match rules and message dispatching: they need to be done in
  kernel space. Otherwise we would still need to context switch to the
  dispatcher (dbus-daemon) so there would be no gain.

- Security policy: I want to explore netlink to let dbus-daemon uploads
  them to kdbus. At the moment, it is not implemented, so it is open
  for all :-)

- Creating the buses: buses are still initiated from user land when
  dbus-daemon listen() on an AF_DBUS socket. Nothing changes here
  compared to other socket types.

- D-Bus activation: I am thinking to let dbus-daemon do that unless you
  have a better proposition. The prototype deliver a message to
  dbus-daemon when the recipient is a well-known name absent from the
  bus. So the kernel module does not need to know the list of
  activatable services. In this case, dbus-daemon wakes up but it is
  not a performance problem.

- Client authentication: I don't know. At the moment, the prototype let
  dbus-daemon handling that by delivering all messages which does not
  look like a D-Bus message (i.e. the NULL byte and the commands like
  "AUTH", "BEGIN", etc.) to dbus-daemon.

- The bus driver (who replies to D-Bus method calls to
  org.freedesktop.DBus): I don't see the value to put this in the
  kernel but I'm happy to be proven wrong. kdbus needs to know which
  connection own which unique name and well-known name. In the
  prototype, kdbus spies the "NameAcquired" and "NameLost" signals for
  that purpose.-- 
Alban

Does the kernel dbus do the validation/parsing/message-modification
that the daemon does? How much of the perf gain is due to different
behavior/semantics vs. avoiding the context switch and copies?

Havoc

Le Fri, 17 Sep 2010 11:28:24 -0400,
Havoc Pennington  a écrit :

> Does the kernel dbus do the validation/parsing/message-modification
> that the daemon does?No. It does the minimum parsing required to route the messages (header
fields 'sender', 'destination', 'interface', etc.). There is no
validation, except a few incomplete ones in the headers of the message.> How much of the perf gain is due to different
> behavior/semantics vs. avoiding the context switch and copies?I don't know, I need to test that. Is there an easy way to disable
validation in dbus-daemon?-- 
Alban

Hi,On Fri, Sep 17, 2010 at 11:37 AM, Alban Crequy
 wrote:
>
> No. It does the minimum parsing required to route the messages (header
> fields 'sender', 'destination', 'interface', etc.). There is no
> validation, except a few incomplete ones in the headers of the message.
>OK. You have to set the sender header, for example, to be correct with
daemon semantics. (This is what I mean about the test suite.)>> How much of the perf gain is due to different
>> behavior/semantics vs. avoiding the context switch and copies?
>
> I don't know, I need to test that. Is there an easy way to disable
> validation in dbus-daemon?Yeah, there is a pretty easy code hack. in
dbus-message.c:load_message() change the validation mode set at the
top.

This still won't disable header _parsing_ though which is itself a lot
slower than it should be in libdbus. The only performance thing
libdbus really gets right is that it avoids a lot of gratuitous
copying of the message.

Havoc

Le Fri, 17 Sep 2010 11:47:28 -0400,
Havoc Pennington  a écrit :

> Hi,
> 
> On Fri, Sep 17, 2010 at 11:37 AM, Alban Crequy
>  wrote:
> >
> > No. It does the minimum parsing required to route the messages
> > (header fields 'sender', 'destination', 'interface', etc.). There
> > is no validation, except a few incomplete ones in the headers of
> > the message.
> >
> 
> OK. You have to set the sender header, for example, to be correct with
> daemon semantics. (This is what I mean about the test suite.)Yes, it sets the 'sender' header correctly when dbus-daemon is bypassed.
But it is not set when the message is delivered to dbus-daemon (for
D-Bus activation, for the bus driver, or other cases).> >> How much of the perf gain is due to different
> >> behavior/semantics vs. avoiding the context switch and copies?
> >
> > I don't know, I need to test that. Is there an easy way to disable
> > validation in dbus-daemon?
> 
> Yeah, there is a pretty easy code hack. in
> dbus-message.c:load_message() change the validation mode set at the
> top.
> 
> This still won't disable header _parsing_ though which is itself a lot
> slower than it should be in libdbus. The only performance thing
> libdbus really gets right is that it avoids a lot of gratuitous
> copying of the message.Thanks for the pointer.

Alban

Le Fri, 17 Sep 2010 11:47:28 -0400,
Havoc Pennington  a écrit :

> >> How much of the perf gain is due to different
> >> behavior/semantics vs. avoiding the context switch and copies?
> >
> > I don't know, I need to test that. Is there an easy way to disable
> > validation in dbus-daemon?
> 
> Yeah, there is a pretty easy code hack. in
> dbus-message.c:load_message() change the validation mode set at the
> top.
> 
> This still won't disable header _parsing_ though which is itself a lot
> slower than it should be in libdbus. The only performance thing
> libdbus really gets right is that it avoids a lot of gratuitous
> copying of the message.I ran the test dbus-ping-pong on KVM/i386 with 50.000 calls using this
patch to enable and disable the validation:
--- a/dbus/dbus-message.c
+++ b/dbus/dbus-message.c
@@ -3913,7 +3913,7 @@
   DBusValidationMode mode;
   dbus_uint32_t n_unix_fds = 0;-  mode = DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED;
+  mode = DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY;
   
   oom = FALSE;I can enable or disable the validation in dbus-ping-pong and in
dbus-daemon separately because once a program is dynamically linked to
a version of libdbus, it stays to that version in memory when I update
libdbus to another version.


First, results without kdbus:
- Validation enabled:        19.2s
- Validation in client only: 18.4s
- Validation in server only: 18.3s
- Validation disabled:       17.7s (-8%)

Then, results with kdbus:
- Validation enabled:         9.3s
- Validation in client only:  9.3s
- Validation in server only:  8.4s
- Validation disabled:        8.4s (-9%)

The improved performance without validation are limited in this test
because the D-Bus messages in dbus-ping-pong contain only a short
string "Hello world". But 8% or 9% is still important.

In the kdbus tests, whether validation in dbus-daemon is enabled does
not change the results. This is consistent since dbus-daemon does not
receive the messages.

The duration with kdbus are around half the duration without kdbus.-- 
Alban

Em Sexta-feira 17 Setembro 2010, às 17:21:32, Alban Crequy escreveu:
> - Match rules and message dispatching: they need to be done in
>   kernel space. Otherwise we would still need to context switch to the
>   dispatcher (dbus-daemon) so there would be no gain.Like we discussed here a month ago or so, we can split up the match processing 
into kernel-space rules and rules that require a user-space helper (like 
netfilter). This would allow the kernel to do fast matching of the most common 
rules used by applications, leaving the complex and uncommon rules to be 
handled by the user-space, with a performance penalty.> - Security policy: I want to explore netlink to let dbus-daemon uploads
>   them to kdbus. At the moment, it is not implemented, so it is open
>   for all :-)We should also discuss which security policies we think still make sense. 
According to the reaction here on the mailing list, maybe reducing the 
complexity of the policies is in order.> - Creating the buses: buses are still initiated from user land when
>   dbus-daemon listen() on an AF_DBUS socket. Nothing changes here
>   compared to other socket types.listen() with sockaddr_dbus?

Interesting.> - D-Bus activation: I am thinking to let dbus-daemon do that unless you
>   have a better proposition. The prototype deliver a message to
>   dbus-daemon when the recipient is a well-known name absent from the
>   bus. So the kernel module does not need to know the list of
>   activatable services. In this case, dbus-daemon wakes up but it is
>   not a performance problem.Makes sense.> - Client authentication: I don't know. At the moment, the prototype let
>   dbus-daemon handling that by delivering all messages which does not
>   look like a D-Bus message (i.e. the NULL byte and the commands like
>   "AUTH", "BEGIN", etc.) to dbus-daemon.I consider the everything that happens before the Hello message, like the 
authentication and feature negotiation, to be out-of-band data. It's a 
handshake for the channel and doesn't have to be there for other transports.

So you can completely replace that handshake with fields in the sockaddr_dbus 
structure and ioctls, like finding out which features got enabled.> - The bus driver (who replies to D-Bus method calls to
>   org.freedesktop.DBus): I don't see the value to put this in the
>   kernel but I'm happy to be proven wrong. kdbus needs to know which
>   connection own which unique name and well-known name. In the
>   prototype, kdbus spies the "NameAcquired" and "NameLost" signals for
>   that purpose.spies? Did you mean "sends" ?

Le Fri, 17 Sep 2010 18:13:22 +0200,
Thiago Macieira  a écrit :

> Em Sexta-feira 17 Setembro 2010, às 17:21:32, Alban Crequy escreveu:

> > - The bus driver (who replies to D-Bus method calls to
> >   org.freedesktop.DBus): I don't see the value to put this in the
> >   kernel but I'm happy to be proven wrong. kdbus needs to know which
> >   connection own which unique name and well-known name. In the
> >   prototype, kdbus spies the "NameAcquired" and "NameLost" signals
> > for that purpose.
> 
> spies? Did you mean "sends" ?I meant that in the current prototype, the kernel does not generate any
D-Bus message and does not implement the bus driver
org.freedesktop.DBus. It just forwards messages from/to dbus-daemon and
read the content of some of the messages. It works as follow:

- application1 sends the message Hello() on the AF_DBUS socket
- kdbus delivers the message Hello() only to dbus-daemon because the
  destination field is "org.freedesktop.DBus"
- dbus-daemon decides to name the connection ":1.1"
- dbus-daemon sends the signal "NameAcquired" with ":1.1" on the AF_DBUS
  socket
- kdbus parses the "NameAcquired" signal and gets to know that
  dbus-daemon decided to name the connection ":1.1". It stores that
  unique name in the socket structure. And it delivers the signal
  containing ":1.1" without modification to application1.

So I could test a full GNOME session (and also N900) with AF_DBUS
without implementing the bus driver in the kernel.-- 
Alban

Hi,> So I could test a full GNOME session (and also N900) with AF_DBUS
> without implementing the bus driver in the kernel.So this puts the session bus in the kernel?

To me, putting the /system/ bus in the kernel makes some sense because
the lifetime of the system bus is the lifetime of the system.  Just
like the kernel.  But I guess for me this solves more interesting
political problems than performance problems:

1) Put an end to the tired debate on whether or not it's okay to
restart the system bus on upgrades
2) Put an end to the auditd controversy involving audit trails
3) Put an end to the (albeit mostly fizzled out in the last couple
years) vitriolic and ignorant ideas that d-bus is "just more desktop
bloat needed for NotworkManager and *Kits"

To me, the context switch minimization and slightly better performance
should just be incidental.  d-bus is designed for low-frequency
control messaging anyway.  When its peformance is a measurable
bottleneck, it's a sign it's not being used for what it's intended
for.

How do you handle more than one session bus?  Tie it to kernel
keyring?  generate random string in the userspace half like with
AF_UNIX sockets?

--Ray

Le Fri, 17 Sep 2010 14:07:26 -0400,
Ray Strode  a écrit :

> Hi,
> 
> > So I could test a full GNOME session (and also N900) with AF_DBUS
> > without implementing the bus driver in the kernel.
> So this puts the session bus in the kernel?It depends what is in /etc/dbus-1/{session,system}.conf. If there is:
  <listen>unix:tmpdir=/tmp</listen>
it uses the usual AF_UNIX sockets. If I change it to:
  <listen>dbus:path=/tmp/kdbus</listen>
then it use AF_DBUS sockets with kdbus.

I tested changing both session.conf and system.conf in order test kdbus
on both the session and system bus. For the system bus, I also needed
to change the default bus address in libdbus/configure.in because the
environment variable $DBUS_SYSTEM_BUS_ADDRESS is not set.> To me, putting the /system/ bus in the kernel makes some sense because
> the lifetime of the system bus is the lifetime of the system.  Just
> like the kernel.But the bus system should not be started as early as the kernel boot,
at least not before some userspace application read the policy in the
configuration file and set up the bus correctly. It makes sense that
the system bus is created and configured by userspace.

In the prototype, a bus is created when an application bind() and
listen() on an AF_DBUS socket. kdbus doesn't know about the 2 kinds of
bus (system or session). There is several buses when several AF_DBUS
sockets are bound with a different name.> But I guess for me this solves more interesting
> political problems than performance problems:
> 
> 1) Put an end to the tired debate on whether or not it's okay to
> restart the system bus on upgrades
> 2) Put an end to the auditd controversy involving audit trails
> 3) Put an end to the (albeit mostly fizzled out in the last couple
> years) vitriolic and ignorant ideas that d-bus is "just more desktop
> bloat needed for NotworkManager and *Kits"
> 
> To me, the context switch minimization and slightly better performance
> should just be incidental.  d-bus is designed for low-frequency
> control messaging anyway.  When its peformance is a measurable
> bottleneck, it's a sign it's not being used for what it's intended
> for.
> 
> How do you handle more than one session bus?  Tie it to kernel
> keyring?  generate random string in the userspace half like with
> AF_UNIX sockets?I didn't really tested several session buses, but different bound names
would create different buses. At least it works for 2 buses (1 system
and 1 session).-- 
Alban

Hello,On Saturday 18 September 2010, Alban Crequy wrote:
> Le Fri, 17 Sep 2010 14:07:26 -0400,
> 
> Ray Strode  a écrit :
> > Hi,
> > 
> > > So I could test a full GNOME session (and also N900) with AF_DBUS
> > > without implementing the bus driver in the kernel.
> > 
> > So this puts the session bus in the kernel?
> 
> It depends what is in /etc/dbus-1/{session,system}.conf. If there is:
>   <listen>unix:tmpdir=/tmp</listen>
> it uses the usual AF_UNIX sockets. If I change it to:
>   <listen>dbus:path=/tmp/kdbus</listen>
> then it use AF_DBUS sockets with kdbus.I expect such an abomination to be burnt in flames on the kernel mailing list. 
There is no file "type" for DBus bus, so you simply cannot use the file system 
for this - only Unix/local domain sockets are allowed to sit there. Anything 
else will break stat() semantics, in my understanding.

You should really consider using something else for the sockaddr. It can be as 
simple as an unique integer automatically assigned when listen() gets called, 
fetched with getsockname(). As an added bonus, it becomes trivial to start 
DBus early in the boot.-- 
Rémi Denis-Courmont
http://www.remlab.net/

Hi Remi,> > > > So I could test a full GNOME session (and also N900) with AF_DBUS
> > > > without implementing the bus driver in the kernel.
> > > 
> > > So this puts the session bus in the kernel?
> > 
> > It depends what is in /etc/dbus-1/{session,system}.conf. If there is:
> >   <listen>unix:tmpdir=/tmp</listen>
> > it uses the usual AF_UNIX sockets. If I change it to:
> >   <listen>dbus:path=/tmp/kdbus</listen>
> > then it use AF_DBUS sockets with kdbus.
> 
> I expect such an abomination to be burnt in flames on the kernel mailing list. 
> There is no file "type" for DBus bus, so you simply cannot use the file system 
> for this - only Unix/local domain sockets are allowed to sit there. Anything 
> else will break stat() semantics, in my understanding.correct. Using path= is wrong. The sockaddr_dbus struct should be
properly defined. Essentially just some like type=session and uuid=...
or something should be enough.> You should really consider using something else for the sockaddr. It can be as 
> simple as an unique integer automatically assigned when listen() gets called, 
> fetched with getsockname(). As an added bonus, it becomes trivial to start 
> DBus early in the boot.Actually the kernel should just start the system bus. No reason to wait
for userspace. That way we can remove all needed magic handling in init
daemons like systemd. The D-Bus system bus is just present and always
present as long as the kernel is running.

These days we do have the problem of dbus-daemon crashing and no
application is capable of handling this. That would be once and for all
solved with the kernel just handling the system bus.

Death of the system bus is fatal for every modern Linux system these
days.

Regards

Marcel

Hello,On Saturday 18 September 2010, Marcel Holtmann wrote:
> Hi Remi,
> 
> > > > > So I could test a full GNOME session (and also N900) with AF_DBUS
> > > > > without implementing the bus driver in the kernel.
> > > > 
> > > > So this puts the session bus in the kernel?
> > > 
> > > It depends what is in /etc/dbus-1/{session,system}.conf. If there is:
> > >   <listen>unix:tmpdir=/tmp</listen>
> > > 
> > > it uses the usual AF_UNIX sockets. If I change it to:
> > >   <listen>dbus:path=/tmp/kdbus</listen>
> > > 
> > > then it use AF_DBUS sockets with kdbus.
> > 
> > I expect such an abomination to be burnt in flames on the kernel mailing
> > list. There is no file "type" for DBus bus, so you simply cannot use the
> > file system for this - only Unix/local domain sockets are allowed to sit
> > there. Anything else will break stat() semantics, in my understanding.
> 
> correct. Using path= is wrong. The sockaddr_dbus struct should be
> properly defined. Essentially just some like type=session and uuid=...
> or something should be enough.
> 
> > You should really consider using something else for the sockaddr. It can
> > be as simple as an unique integer automatically assigned when listen()
> > gets called, fetched with getsockname(). As an added bonus, it becomes
> > trivial to start DBus early in the boot.
> 
> Actually the kernel should just start the system bus. No reason to wait
> for userspace. That way we can remove all needed magic handling in init
> daemons like systemd. The D-Bus system bus is just present and always
> present as long as the kernel is running.That would assume the kernel can handle everything that you'd expect from the 
bus. I doubt that's going to happen. For a start, DBus activation cannot be 
done from the kernel alone, just like modprobe.

Maybe the init process should spawn the bus, and I would hardly be surprised 
if systemd did, but that's a different discussion.-- 
Rémi Denis-Courmont
http://www.remlab.net/

Hi Remi,> > > You should really consider using something else for the sockaddr. It can
> > > be as simple as an unique integer automatically assigned when listen()
> > > gets called, fetched with getsockname(). As an added bonus, it becomes
> > > trivial to start DBus early in the boot.
> > 
> > Actually the kernel should just start the system bus. No reason to wait
> > for userspace. That way we can remove all needed magic handling in init
> > daemons like systemd. The D-Bus system bus is just present and always
> > present as long as the kernel is running.
> 
> That would assume the kernel can handle everything that you'd expect from the 
> bus. I doubt that's going to happen. For a start, DBus activation cannot be 
> done from the kernel alone, just like modprobe.that is not a problem at all. The kernel could just craft a D-Bus
message and send it off to systemd (or upstart for that matter). That
being the init process will then just start the daemon and babysit it.

And of course with kernel managing the bus users, it knows when systemd
has been started and attached itself to the bus. Also since systemd is
the init process the kernel also knows when that got started anyway.

Regards

Marcel

On Friday 17. September 2010 18.37.38 Alban Crequy wrote:
> So I could test a full GNOME session (and also N900) with AF_DBUS
> without implementing the bus driver in the kernel.Would you mind also testing a KDE 4 session and starting and quitting some 
apps? Please make sure you're using a recent version, since that one also uses 
D-Bus for the system tray icons.

All applications in KDE connect to D-Bus, so this should prove to be a stress-
test for your code. Not to mention that you test a different binding's 
behaviour (QtDBus).

KDE has had a number of issues with D-Bus, to the point that some apps simply 
can't use D-Bus 1.2. All distributions are being urged to upgrade to 1.4 as 
soon as possible. (Threading bugs fixed in the lib)

Hi,On Fri, Sep 17, 2010 at 11:21 AM, Alban Crequy
 wrote:
> - D-Bus activation: I am thinking to let dbus-daemon do that unless you
>  have a better propositionI don't have a better proposal, but one controversial issue with dbus
activation right now is that it doesn't preserve the login uid of the
client initiating the activation, which is a big deal for certain
groups of people who want a proper trail in their auditd logs.

In theory if this was handled on the kernel side it could set the
login uid properly on the activated process instead of using the login
uid of the bus daemon.

--Ray

On 17 September 2010 18:52, Ray Strode  wrote:
> In theory if this was handled on the kernel side it could set the
> login uid properly on the activated process instead of using the login
> uid of the bus daemon.I'm not sure this makes sense, as packagekitd can be auto-started by
user 'bob' and then used to install a package, and then user 'sally'
can use the same daemon instance to remove a package. The daemon only
quits after 10 seconds of idleness.

Requiring system-activated daemon to quit after ever user action would
demolish performance IMHO.

Richard.

On 20 September 2010 13:54, Steve Grubb  wrote:
> What you would need is a way for sally to tell the kernel that she wants to
> take responsibility for any actions the daemon performs. In cases where the
> daemon is truly multi-user, it should probably have its own uid like any other
> daemon.Both correct points.

Richard.

Hi,On Mon, Sep 20, 2010 at 5:30 AM, Richard Hughes  wrote:
> On 17 September 2010 18:52, Ray Strode  wrote:
>> In theory if this was handled on the kernel side it could set the
>> login uid properly on the activated process instead of using the login
>> uid of the bus daemon.
>
> I'm not sure this makes sense, as packagekitd can be auto-started by
> user 'bob' and then used to install a package, and then user 'sally'
> can use the same daemon instance to remove a package. The daemon only
> quits after 10 seconds of idleness.Ah right, and that's a very reasonable thing for it to do.> Requiring system-activated daemon to quit after ever user action would
> demolish performance IMHO.Clearly that would be suboptimal.  There probably needs to be a way to
tell the kernel some "surrogate uid".  It wouldn't have to be the uid
itself, I guess--it could just be the fd of the client connection.

So, you're right, it seems like this isn't something we can solve
solely by putting the system bus in the kernel, since fundamentally it
requires each system service to somehow define client work boundaries,
and only the system service, not the bus and not the kernel know what
those boundaries are.

--Ray

Le Mon, 20 Sep 2010 10:30:26 +0100,
Richard Hughes  a écrit :

> On 17 September 2010 18:52, Ray Strode  wrote:
> > In theory if this was handled on the kernel side it could set the
> > login uid properly on the activated process instead of using the
> > login uid of the bus daemon.
> 
> I'm not sure this makes sense, as packagekitd can be auto-started by
> user 'bob' and then used to install a package, and then user 'sally'
> can use the same daemon instance to remove a package. The daemon only
> quits after 10 seconds of idleness.
> 
> Requiring system-activated daemon to quit after ever user action would
> demolish performance IMHO.In the same way the ability to send file descriptor in D-Bus message
with SCM_RIGHTS ancillary data was added in D-Bus 1.3.0, the
D-Bus protocol could be enhanced to send SCM_CREDENTIALS ancillary data
(see man unix(7)) with pid, uid and gid. The value pid+uid+gid sent by
a process are checked by the kernel, so the process cannot write random
values.

With the current dbus-daemon, it would not work because when
dbus-daemon relays the D-Bus message, the kernel would check the
pid+uid+gid values against the process dbus-daemon and dbus-daemon is
not running as root, so the kernel will not let it fake the IDs.

But if a D-Bus message is delivered directly (with a peer to peer
D-Bus connection or with kdbus bypassing dbus-daemon), the pid+uid+gid
will be correct and checked by the kernel.

In your example, packagekitd can run as a privileged user with D-Bus
activation, auto-started by either 'bob' or 'sally' but when they send
D-Bus method calls to install and remove packages, packagekitd would
know which user initiated each request and could log that. It would not
be the login uid, but maybe it is enough for auditd?

The daemon would not need to be restarted after every user action.

Alban

Hi,On Wed, Oct 6, 2010 at 12:10 PM, Alban Crequy
 wrote:
> In the same way the ability to send file descriptor in D-Bus message
> with SCM_RIGHTS ancillary data was added in D-Bus 1.3.0, the
> D-Bus protocol could be enhanced to send SCM_CREDENTIALS ancillary data
> (see man unix(7)) with pid, uid and gid.It uses that stuff now to verify security policy, and provide
GetUnixProcessId etc.> The value pid+uid+gid sent by
> a process are checked by the kernel, so the process cannot write random
> values.Well, you actually can spoof that data if you're root, but that's
neither here nor there I guess.> In your example, packagekitd can run as a privileged user with D-Bus
> activation, auto-started by either 'bob' or 'sally' but when they send
> D-Bus method calls to install and remove packages, packagekitd would
> know which user initiated each request and could log that. It would not
> be the login uid, but maybe it is enough for auditd?I'm not sure if that meets the needs of the audit folks.  They want
something that userspace can't easily fake.
I'm not sure where the line is, though.

One things clear to me now, if you've got one service serving multiple
clients, that service is the only one that knows when a given client
is being served. It's not something the kernel can really guess or
figure out implicitly without adding more api.

I had a litte conversation with ajax about this a while back:

http://people.freedesktop.org/~halfline/telli...

(he also needs to be able to tell the kernel when X is serving a
particular client)

--Ray

On 09/16/2010 06:23 AM, Soh Kam Yung wrote:
> Just spotted this interesting post about putting d-bus in the kernel [
> http://alban.apinc.org/blog/2010/09/15/d-bus-... ]
>
> Fascinating work.Well maybe fascinating, and possibly technical a challenge and possible,
but the question is about do we want a inter proces communication suite 
to be in the kernel??

In my opinion this should not go into the kernel. This is not the task 
of the kernel.

Stef Bon> ====
> September 15, 2010
> D-Bus in the kernel, faster!
> Filed under: General, Hacking, Informatique, maemo — alban @ 4:03 pm
>
> In the last few weeks, I worked on having D-Bus directly in the Linux
> kernel to improve its performances. I based my work on what Ian Molton
> did. For now it’s just a prototype, but some benchmarks I did show a
> good performance improvement.
>
> [...]
>
> The first benchmark is dbus-ping-pong. It is a simple tool to call a
> D-Bus method and wait for the reply 10000 times. I tried it both on a
> KVM/i386 virtual machine and on a N900/arm.
>
>      * KVM/i386, without kdbus: 3.887s
>      * KVM/i386, with kdbus: 2.085s (x1.8)
>      * N900/arm, without kdbus: 28.00s
>      * N900/arm, with kdbus: 9.23s (x3)
>
> [...]
> ====

Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
> Well maybe fascinating, and possibly technical a challenge and possible,
> but the question is about do we want a inter proces communication suite 
> to be in the kernel??
> 
> In my opinion this should not go into the kernel. This is not the task 
> of the kernel.I quite disagree. I think that an IPC mechanism providing rendezvousing and 
routing of messages (many-to-many) is quite welcome and should be provided by 
the kernel.

Am Fri, 17 Sep 2010 18:14:33 +0200
schrieb Thiago Macieira :

> Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
> > Well maybe fascinating, and possibly technical a challenge and
> > possible, but the question is about do we want a inter proces
> > communication suite to be in the kernel??
> > 
> > In my opinion this should not go into the kernel. This is not the
> > task of the kernel.
> 
> I quite disagree. I think that an IPC mechanism providing
> rendezvousing and routing of messages (many-to-many) is quite welcome
> and should be provided by the kernel.Nothing beats a discussion with well founded arguments...

In any case this is an interesting experiment. The prototype is still
shaping up, in the worst case it is a solid excuse to improve the
specification. And I find it somewhat exciting that a proven interface
is proposed for the kernel, as opposed to something written without
ever asking user space developers.-- 
ciao,
    Christian

On 09/17/2010 06:14 PM, Thiago Macieira wrote:
> Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
>> Well maybe fascinating, and possibly technical a challenge and possible,
>> but the question is about do we want a inter proces communication suite 
>> to be in the kernel??
>>
>> In my opinion this should not go into the kernel. This is not the task 
>> of the kernel.
> 
> I quite disagree. I think that an IPC mechanism providing rendezvousing and 
> routing of messages (many-to-many) is quite welcome and should be provided by 
> the kernel.Instead of agreeing or disagreeing, I would wish for something else: That any
design decisions in free software in general, and in an IPC system in
particular, and especially for an IPC system in the kernel, are based on solid
design principles that are articulated and defended.

My understanding is that DBus has come from the Gnome experience with Corba
and other similar systems (specifically dcop).  My personal experience is from
microkernels (Mach, L4, KeyKOS/EROS), which also provide communication
facilities (in fact, that and memory/cpu management are their main features).
 And the facilities that the latest generations of microkernels provide look
nothing like DBus.  Without going into details, at least for the design of
those IPC systems their reasons are well articulated and documented.  The
desired properties are stated and the design is shown to fulfill these demands.

For DBus, alas, I find it hard to find any documentation in this regard.
http://lists.freedesktop.org/archives/dbus/20...
seems to come close, but it is actually a negative statement, in that the
stated requirements are peripheral (control, license, implementation language
etc).  If DBus were a stable interface, its properties could be analyzed after
the fact, but the discussion on file descriptor passing for example showed
that there is still substantial flux.

Thanks,
Marcus

Hi,On Tue, Sep 21, 2010 at 8:49 AM, Marcus Brinkmann
 wrote:
> Instead of agreeing or disagreeing, I would wish for something else: That any
> design decisions in free software in general, and in an IPC system in
> particular, and especially for an IPC system in the kernel, are based on solid
> design principles that are articulated and defended.
>The intro to the spec tries to answer this:
http://dbus.freedesktop.org/doc/dbus-specific...

A couple of omitted things there include,
* "low-overhead" and efficiency requirements in general don't extend
to "lots of data"; dbus is a "control" rather than "transfer" protocol
* "low latency" refers to the lack of need to block on a round trip,
not to the length of time spent on a round trip
* ease of use generally trumps performance in the design, the
performance goals were to avoid blocking round trips and avoid huge
overhead like XML parsing, but while avoiding those major nasties,
being significantly slower than raw sockets was considered fine
* there is absolutely no attempt to have anything to do with what
server developers usually think of as "messaging"; dbus has zip, zero,
nada to do with distributed computing

An important point the spec intro does mention offhand is that dbus is
as much about some "process lifecycle and discovery" facilities as it
is about IPC. The problem being solved was not primarily "how do I
marshal an integer on the wire" but more "how do I start up and locate
and keep track of the things to send my integer to"

Havoc

Em Terça-feira 21 Setembro 2010, às 14:49:13, Marcus Brinkmann escreveu:
> For DBus, alas, I find it hard to find any documentation in this regard.
> http://lists.freedesktop.org/archives/dbus/20...
> seems to come close, but it is actually a negative statement, in that the
> stated requirements are peripheral (control, license, implementation
> language etc).  If DBus were a stable interface, its properties could be
> analyzed after the fact, but the discussion on file descriptor passing for
> example showed that there is still substantial flux.The file descriptor change was extremely minor compared to the rest. There was 
never any discussion of the wire protocol after the agreement that adding file-
descriptor passing was a good thing.

The wire protocol is very stable and that's what matters. If you want to have 
a discussion, just go ahead.

The user-level API, especially that exposed by libdbus-1 is irrelevant for 
your discussion.

On Tue, 21.09.10 14:49, Marcus Brinkmann  wrote:

> On 09/17/2010 06:14 PM, Thiago Macieira wrote:
> > Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
> >> Well maybe fascinating, and possibly technical a challenge and possible,
> >> but the question is about do we want a inter proces communication suite 
> >> to be in the kernel??
> >>
> >> In my opinion this should not go into the kernel. This is not the task 
> >> of the kernel.
> > 
> > I quite disagree. I think that an IPC mechanism providing rendezvousing and 
> > routing of messages (many-to-many) is quite welcome and should be provided by 
> > the kernel.
> 
> Instead of agreeing or disagreeing, I would wish for something else: That any
> design decisions in free software in general, and in an IPC system in
> particular, and especially for an IPC system in the kernel, are based on solid
> design principles that are articulated and defended.
> 
> My understanding is that DBus has come from the Gnome experience with Corba
> and other similar systems (specifically dcop).  My personal experience is from
> microkernels (Mach, L4, KeyKOS/EROS), which also provide communication
> facilities (in fact, that and memory/cpu management are their main features).
>  And the facilities that the latest generations of microkernels provide look
> nothing like DBus.  Without going into details, at least for the design of
> those IPC systems their reasons are well articulated and documented.  The
> desired properties are stated and the design is shown to fulfill these demands.Well, there's quite a bit of a difference between IPC for microkernels
and IPC for ... well ... real-life applications.

Note that the D-Bus spec in great detail focusses on marshalling and
validation of marshalled data. To my knowledge this is out of scope for
the microkernel stuff but crucial for usage in desktopy apps, and hence
you are comparing oranges and apples.

Note that the D-Bus marshalling and semantics are actually flexibly
enough defined so that we could add additional transports underneath. A
longterm item on the todo list for example is an SSL transport. And
similarly you could of course implement a microkernel transport for this
too.

The way I see D-Bus is that it mostly focusses on the logic that's above
the transport layer. Since sockets are the primary IPC system on
Unix-like systems (and as a matter of fact on almost all other real-life
systems too) the spec then goes on and defines the protocol how it is
used for AF_UNIX and AF_INET sockets. But that doesn't mean that one
a) couldn't port it to other transports or b) couldn't extend the
current transports in a comptible fashion to learn new tricks.

Note that local multicasting has been available on Linux for quite some
time in the AF_NETLINK protocol, and is widely used (for example libudev
is based on it). Like almost any other real-life multicasting it is not
reliable however, and drops packets when the recv queues run over.

That siad, if you limit yourself to POSIX then you don't get this
functionality. But well, my recommendation is to forget about POSIX and
just take Linux as the standard interface to code against.

Lennart-- 
Lennart Poettering - Red Hat, Inc.

Em Quarta-feira 22 Setembro 2010, às 13:53:47, Lennart Poettering escreveu:
> That siad, if you limit yourself to POSIX then you don't get this
> functionality. But well, my recommendation is to forget about POSIX and
> just take Linux as the standard interface to code against.Especially if we're talking about a *Linux* kernel module for IPC. :-)

Hello,On Friday 17 September 2010, Thiago Macieira wrote:
> Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
> > Well maybe fascinating, and possibly technical a challenge and possible,
> > but the question is about do we want a inter proces communication suite
> > to be in the kernel??
> > 
> > In my opinion this should not go into the kernel. This is not the task
> > of the kernel.
> 
> I quite disagree. I think that an IPC mechanism providing rendezvousing and
> routing of messages (many-to-many) is quite welcome and should be provided
> by the kernel.Yes and no. I would agree that POSIX lacks a proper mechanism for multicasting 
message (it seems using IP multicast on loopback is the only way). That's one 
thing where DBus signals are really useful. Service 'name resolutoin' is also 
nice to have.

But when it comes to request/response messages, it would be far more efficient 
to establish a direct connection between the client and the server. This would 
not only move most traffic out of the way of the DBus bus daemon, thus 
increasing perfomance. It would also solve the head-of-line blocking problem 
that is inherent to multiplexing multiple flows of informations over a single 
stream (Unix socket).

But it's too late now.-- 
Rémi Denis-Courmont
http://www.remlab.net/

Hi,2010/9/21 Rémi Denis-Courmont :
> proper mechanism for multicasting message
> Service 'name resolutoin' is also nice to have.With dbus, these are more like the primary reason for it to exist.> But when it comes to request/response messages, it would be far more efficient
> to establish a direct connection between the client and the server. This would
> not only move most traffic out of the way of the DBus bus daemon, thus
> increasing perfomance.And it would break the actual dbus use-cases. Not all IPC is the same!

The performance overhead of the bus does not matter for anything dbus
was actually designed for. What would matter, would be if every app
had a socket to every other app, instead of the "star" layout. Or
losing the ability to broadcast.

The way you do a performant link to to send lots of data, if dbus is
involved at all, is to use dbus to set up the link; and then on that
link you _could_ use dbus in 1-to-1 daemonless mode, or you could use
an IPC protocol appropriate for whatever you are doing.

Anyway designing IPC systems without clear use-cases isn't going to go
anywhere. The point of dbus is/was to solve these multicast and
lifecycle issues, not to be a faster kind of socket. If you want a
socket open a socket, not a dbus connection.> It would also solve the head-of-line blocking problem
> that is inherent to multiplexing multiple flows of informations over a single
> stream (Unix socket).This only happens between any two dbus daemon clients; the daemon
won't block to read or write to any client. So yes if message A is
going from client 1 to client 2, both of those clients have to wait on
message A. But other clients do not.

Havoc

Hello,On Tuesday 21 September 2010, Havoc Pennington wrote:
> > But when it comes to request/response messages, it would be far more
> > efficient to establish a direct connection between the client and the
> > server. This would not only move most traffic out of the way of the DBus
> > bus daemon, thus increasing perfomance.
> 
> And it would break the actual dbus use-cases. Not all IPC is the same!
> 
> The performance overhead of the bus does not matter for anything dbus
> was actually designed for. What would matter, would be if every app
> had a socket to every other app, instead of the "star" layout. Or
> losing the ability to broadcast.So you're saying Telepathy should not use DBus the way it does, I guess.> The way you do a performant link to to send lots of data, if dbus is
> involved at all, is to use dbus to set up the link; and then on that
> link you _could_ use dbus in 1-to-1 daemonless mode, or you could use
> an IPC protocol appropriate for whatever you are doing.Sure. But it seemed to me that libdbus did not really make peer-to-peer DBus 
so easy (though it certainly allows it).> Anyway designing IPC systems without clear use-cases isn't going to go
> anywhere. The point of dbus is/was to solve these multicast and
> lifecycle issues, not to be a faster kind of socket. If you want a
> socket open a socket, not a dbus connection.I guess I did not mean to say DBus is misdesigned, but misused then. Most 
applications use DBus correctly as a rendez-vous mechanism, but also 
incorrectly for peer-to-peer signaling.> > It would also solve the head-of-line blocking problem
> > that is inherent to multiplexing multiple flows of informations over a
> > single stream (Unix socket).
> 
> This only happens between any two dbus daemon clients; the daemon
> won't block to read or write to any client. So yes if message A is
> going from client 1 to client 2, both of those clients have to wait on
> message A. But other clients do not.If two clients A & B try to send a message to the same client C, one (say B) 
will have to wait for the other (say A).  Then if B also wants to send a 
message to a forth client D, the message to D will be stuck in B's queue. 
Effectively, the communication between B & D ends up being blocked by the 
communication between A & C.

You can mitigate it with low message size limits and/or large receive buffers 
on the bus daemon to *some* extent.-- 
Rémi Denis-Courmont
http://www.remlab.net/

Hi,2010/9/21 Rémi Denis-Courmont :
> So you're saying Telepathy should not use DBus the way it does, I guess.
>I don't really know how Telepathy works. Just based on watching list
traffic, I have the impression it may use dbus in some cases when I
would personally have used a dlopen() module or something. But, again,
I don't really know.> Sure. But it seemed to me that libdbus did not really make peer-to-peer DBus
> so easy (though it certainly allows it).It isn't super easy, though I don't think it's super hard either.
Mostly not much attention here because for the most part nobody has
seemed to need it (or not needed it enough to start patching and/or
suggesting APIs, anyhow)

The one thing that happened in this area was Lennart adding the
fd-passing support, which is one way to set up a peer-to-peer link (in
that case, not one that then speaks dbus though).> I guess I did not mean to say DBus is misdesigned, but misused then. Most
> applications use DBus correctly as a rendez-vous mechanism, but also
> incorrectly for peer-to-peer signaling.It's fine for messages generally. It just isn't good if you're going
to shovel some giant boatload of data or have realtime constraints or
something.

the idea of dbus is if you want to send messages like "open this
document" or "suspend screensaver" or do startup-notification protocol
 or NetworkManager or things like that. These are the 90% case for the
session and system bus. Maybe 95% or more. The other cases just aren't
solved by dbus. But they weren't solved before that, either.> If two clients A & B try to send a message to the same client C, one (say B)
> will have to wait for the other (say A).  Then if B also wants to send a
> message to a forth client D, the message to D will be stuck in B's queue.
> Effectively, the communication between B & D ends up being blocked by the
> communication between A & C.
>
> You can mitigate it with low message size limits and/or large receive buffers
> on the bus daemon to *some* extent.dbus-daemon will buffer any message that's permitted, I think. (i.e.
as long as you're under the size limit that's allowed at all, then
it'll buffer; otherwise it will throw an error up front). If it
doesn't have RAM to buffer it should throw an error. So none of the
clients would actually block. B could send to D even though C has not
read from B yet. Where things would block is if B decided to block for
C to reply. It's up to B whether to do this.

Havoc

On 09/21/2010 07:00 PM, Rémi Denis-Courmont wrote:
> Yes and no. I would agree that POSIX lacks a proper mechanism for multicasting 
> message (it seems using IP multicast on loopback is the only way). That's one 
> thing where DBus signals are really useful. Service 'name resolutoin' is also 
> nice to have.Multicasting, IMO, raises serious resource management issues from a kernel
developers point of view (dunno if Linux people care about that, though).  You
won't find a modern microkernel supporting multicasting.  It's possible, but
very complicated to get right (where right means: no denial of service attacks
against the kernel or the servers, and full reliability, not just
probabilistic guarantees).

OTOH, service name resolution is of course part of POSIX, where it is called
"file system".  The problem here is that it is usually not user extensible
(something that is slowly being addressed with things like FUSE), see
http://www.walfield.org/papers/200707-walfiel...
(disclaimer: I am a co-author of that paper).> But when it comes to request/response messages, it would be far more efficient 
> to establish a direct connection between the client and the server. This would 
> not only move most traffic out of the way of the DBus bus daemon, thus 
> increasing perfomance. It would also solve the head-of-line blocking problem 
> that is inherent to multiplexing multiple flows of informations over a single 
> stream (Unix socket).The most direct connection you can get is shared memory, but even that
requires either lock free protocols or a synchronization primitive such as a
futex.

Thanks,
Marcus

On Tuesday 21. September 2010 20.13.03 Marcus Brinkmann wrote:
> Multicasting, IMO, raises serious resource management issues from a kernel
> developers point of view (dunno if Linux people care about that, though). 
> You won't find a modern microkernel supporting multicasting.  It'sJust an off-topic side-note: IPv6 requires multicasting, and IPv6 is starting 
to be required if you want to connect to the Internet. Mobile operators will 
require it from 2011 onwards (some 2012).

On 09/21/2010 09:32 PM, Thiago Macieira wrote:
> On Tuesday 21. September 2010 20.13.03 Marcus Brinkmann wrote:
>> Multicasting, IMO, raises serious resource management issues from a kernel
>> developers point of view (dunno if Linux people care about that, though). 
>> You won't find a modern microkernel supporting multicasting.  It's
> 
> Just an off-topic side-note: IPv6 requires multicasting, and IPv6 is starting 
> to be required if you want to connect to the Internet. Mobile operators will 
> require it from 2011 onwards (some 2012).Yes, but the network stack doesn't necessarily need to be in the kernel (in
fact, for microkernels it never is).  In any way, you don't need to look at
multicast to find DoS attacks in the internet.  The internet is not robust
against DoS by design (that's a good thing: it has allowed to grow the
internet quickly, and the advantages of that outweigh the lack of security by
far).

By the way, by multicasting I was refering to X-to-many IPC (as the poster I
replied to did).

Thanks,
Marcus