Message-ID: <20150119183352.GA29289@sig21.net>
Date:	Mon, 19 Jan 2015 19:33:52 +0100
From:	Johannes Stezenbach <js@...21.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	arnd@...db.de, ebiederm@...ssion.com, gnomes@...rguk.ukuu.org.uk,
	teg@...m.no, jkosina@...e.cz, luto@...capital.net,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Mack <daniel@...que.org>, dh.herrmann@...il.com,
	tixxdz@...ndz.org
Subject: Re: [PATCH v3 00/13] Add kdbus implementation

(resend, fix Daniel's email address)

Hi Greg and Daniel,

I don't have a clue so I need to ask some stupid questions...

On Fri, Jan 16, 2015 at 11:16:04AM -0800, Greg Kroah-Hartman wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.
> 
> The documentation in the first patch in this series explains the
> protocol and the API details.

How about the big picture?

> Reasons why this should be done in the kernel, instead of userspace as
> it is currently done today include the following:
[abbreviated]
> - performance
> - security
> - semantics for apps with heavy data payloads


First of all I wonder about the relationship with D-Bus.
http://dbus.freedesktop.org/doc/dbus-specification.html says:

   D-Bus is designed for two specific use cases:

       A "system bus" for notifications from the system to user
       sessions, and to allow the system to request input from
       user sessions.

       A "session bus" used to implement desktop environments such
       as GNOME and KDE. 

   D-Bus is not intended to be a generic IPC system for any
   possible application, and intentionally omits many features
   found in other IPC systems for this reason. 

Does this also apply to kdbus?  If not, what are the
suggested uses of kdbus beyond those where D-Bus is
currently used?

Another related quote by Havoc Pennington:
http://lists.freedesktop.org/archives/dbus/2012-March/015024.html

   In general, reading this, I think in some cases there are
   problems that make sense to fix in dbus, and in other cases
   there are problems that are best solved by not using dbus.
   ...
   there are about 10000 IPC solutions already, from ICE (both of
   them) to ZeroMQ to AMQP to CORBA to X11 to HTTP to SOAP to
   WebSockets to SUN-RPC to whatever-the-heck. To me, trying to
   make dbus configurable so that it can substitute for any of
   these is a Bad Idea (tm).

Do you think it also applies to kdbus?


Wrt the performance improvement achieved by kdbus, my impression
about D-Bus is that the number of messages on my system is
about a dozen per minute.  Are there actually any existing
applications using D-Bus that have a performance issue?
Or is this only about future possible uses?


Linked from http://kroah.com/log/blog/2014/01/15/kdbus-details/,
http://lwn.net/Articles/580194/ "The unveiling of kdbus" says:

   Unlike most other kernels, Linux has never had a well-designed
   IPC mechanism. Windows and Mac OS have this feature; even
   Android, based on Linux, has one in the form of the "binder"
   subsystem. Linux, instead, has only had the primitives —
   sockets, FIFOs, and shared memory — but those have never been
   knitted together into a reasonable application-level API. Kdbus
   is an attempt to do that knitting and create something that is
   at least as good as the mechanisms found on other systems.

These are bold words. I'm not sure what Windows and Mac OS
have in terms of IPC, but the above suggests that kdbus
is *the* new Linux IPC that everyone will use for everything,
rather than a special purpose facility.
True?


Thanks,
Johannes
--
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/

Powered by blists - more mailing lists