linux-kernel - Re: [PATCH 01/13] kdbus: add documentation

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]

Message-ID: <CANq1E4TtBhA6Ygu9qMU8xVxbL9q+ZBqnfdU0ceeTTfam9aT+=w@mail.gmail.com>
Date:	Tue, 27 Jan 2015 16:23:28 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Tom Gundersen <teg@...m.no>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Daniel Mack <daniel@...que.org>, Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Andy Lutomirski <luto@...capital.net>,
	Linux API <linux-api@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Johannes Stezenbach <js@...21.net>,
	"Theodore T'so" <tytso@....edu>,
	christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 01/13] kdbus: add documentation

Hi

On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages)
<mtk.manpages@...il.com> wrote:
> On 01/26/2015 04:26 PM, Tom Gundersen wrote:
>> On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
>> <mtk.manpages@...il.com> 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
--
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/