Hi On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> 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@xxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
