linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Apr 2015 14:40:06 -0400
From:	Havoc Pennington <hp@...ox.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Rik van Riel <riel@...hat.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 2:16 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> But can't a dbus library handle this for the apps? Like implementing TCP on
> top of UDP. I really doubt the entire dbus protocol needs to be pushed into
> the kernel.

You could probably do something like assign sequence numbers,
temporarily relax ordering, and then reconstruct the order where
needed, but somebody still has to assign the sequence numbers in
order, and the bus has to process requests in order (it can't flip a
subscribe and an unsubscribe, for example). So I don't know whether
you could get anywhere with it or not.

The current model (userspace dbus daemon, don't know about kdbus) is like this:

 - you have a pool of ordered incoming queues from each client, where
each incoming queue conceptually ends with EOF of course

 - the main bus loop does:
    - pick the head message or EOF from any nonempty incoming queue for dispatch
    - route it according to destination address or subscribers
    - if the destination includes the bus itself (e.g. someone wanting
to subscribe or own a name or whatever) then process the request...
note that this will potentially affect how the next message gets
routed
    - for each destination client, write the message to the ordered
outgoing queue for that client
    - if the incoming queue has EOF then send out notifications about
that to interested clients, clean up bus names, etc.

Conceptually, filling and draining the queues could easily be in
separate threads, though the userspace daemon doesn't do that.

> I'm going to try to spend some time reading about dbus and playing with the
> code (thanks for the links BTW!). Then I can see if I can come up with
> something too. Or at least be able to ask the right questions.
>

Greg may be right to point people to Lennart's C binding which has a
lot less "baggage" than the GLib stuff, which assumes knowledge of the
"glib way"

Havoc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/