From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932231AbbA0PXe (ORCPT ); Tue, 27 Jan 2015 10:23:34 -0500 Received: from mail-ig0-f178.google.com ([209.85.213.178]:48042 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758614AbbA0PX3 (ORCPT ); Tue, 27 Jan 2015 10:23:29 -0500 MIME-Version: 1.0 In-Reply-To: <54C66F30.8050108@gmail.com> References: <1421435777-25306-1-git-send-email-gregkh@linuxfoundation.org> <1421435777-25306-2-git-send-email-gregkh@linuxfoundation.org> <54BE5DC8.70706@gmail.com> <54BE9D08.7010804@zonque.org> <54BF805B.4000609@gmail.com> <54BFDAAA.50203@zonque.org> <54C0CE8A.5080805@gmail.com> <20150123155402.GB2159@kroah.com> <54C65267.7090905@gmail.com> <54C66F30.8050108@gmail.com> Date: Tue, 27 Jan 2015 16:23:28 +0100 Message-ID: Subject: Re: [PATCH 01/13] kdbus: add documentation From: David Herrmann To: "Michael Kerrisk (man-pages)" Cc: Tom Gundersen , Greg Kroah-Hartman , Daniel Mack , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Jiri Kosina , Andy Lutomirski , Linux API , LKML , Djalal Harouni , Johannes Stezenbach , "Theodore T'so" , christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages) wrote: > On 01/26/2015 04:26 PM, Tom Gundersen wrote: >> On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages) >> wrote: >>> 2. Is the API to be invoked directly by applications or is intended to >>> be used only behind specific libraries? You seem to be saying that >>> the latter is the case (here, I'm referring to your comment above >>> about sd-bus). However, when I asked David Herrmann a similar >>> question I got this responser: >>> >>> "kdbus is in no way bound to systemd. There are ongoing efforts >>> to port glib and qt to kdbus natively. The API is pretty simple >>> and I don't see how a libkdbus would simplify things. In fact, >>> even our tests only have slim wrappers around the ioctls to >>> simplify error-handling in test-scenarios." >>> >>> To me, that implies that users will employ the raw kernel API. >> >> The way I read this is that there will (probably) be a handful of >> users, namely the existing dbus libraries: libdus, sd-bus, glib, Qt, >> ell, and maybe a few others. However, third-party developers will not >> know/care about the details of kdbus, they'll just be coding against >> the dbus libraries as before (might be minor changes, but they >> certainly won't need to know anything about the kernel API). Similarly >> to how userspace developers now code against their libc of choice, >> rather than use kernel syscalls directly. > > Thanks, Tom, for the input. I'm still confused though, since elsewhere > in this thread David Herrmann said in response to a question of mine: > > I think we can agree that we want it to be generically useful, > like other ipc mechanisms, including UDS and netlink. > > Again, that sounds to me like the vision is not "a handful of users". > Hopefully Greg and David can clarify. I only expect a handful of users to call the ioctls directly. The libraries that implement the payload-marshaling, in particular. It's a similar situation with netlink. Thanks David