From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756163AbbAZQpr (ORCPT ); Mon, 26 Jan 2015 11:45:47 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:49099 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753137AbbAZQpk (ORCPT ); Mon, 26 Jan 2015 11:45:40 -0500 Message-ID: <54C66F30.8050108@gmail.com> Date: Mon, 26 Jan 2015 17:45:36 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tom Gundersen CC: mtk.manpages@gmail.com, Greg Kroah-Hartman , Daniel Mack , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Jiri Kosina , Andy Lutomirski , Linux API , LKML , David Herrmann , Djalal Harouni , Johannes Stezenbach , "Theodore T'so" , christoph Hellwig Subject: Re: [PATCH 01/13] kdbus: add documentation 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2015 04:26 PM, Tom Gundersen wrote: > Hi Michael, > > 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. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/