Off-topic: D-Bus in the kernel

[Thiago Macieira]

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" ?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2010  -  Munich Oct 11-13  -  San Francisco Nov 1-3
For more information and to register: http://qt.nokia.com/qtdevdays2010
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100917/748728f2/attachment-0001.pgp>