Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932654AbbDOSlS (ORCPT ); Wed, 15 Apr 2015 14:41:18 -0400 Received: from mail-qk0-f181.google.com ([209.85.220.181]:34211 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752040AbbDOSlQ (ORCPT ); Wed, 15 Apr 2015 14:41:16 -0400 MIME-Version: 1.0 In-Reply-To: <20150415181606.GC24936@home.goodmis.org> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> <20150415181606.GC24936@home.goodmis.org> From: Havoc Pennington Date: Wed, 15 Apr 2015 14:40:06 -0400 X-Google-Sender-Auth: 0L9IzO7KMWURWIKXgq2lEgSeRek Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Steven Rostedt Cc: Rik van Riel , One Thousand Gnomes , Greg Kroah-Hartman , Jiri Kosina , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2182 Lines: 47 On Wed, Apr 15, 2015 at 2:16 PM, Steven Rostedt 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/