Hi, On Tue, Jan 20, 2015 at 09:42:59AM -0500, Josh Boyer wrote: > On Tue, Jan 20, 2015 at 9:31 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > > Hi Michael > > > > On Tue, Jan 20, 2015 at 2:53 PM, Michael Kerrisk (man-pages) > > <mtk.manpages@xxxxxxxxx> wrote: > >> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote: > >>> From: Daniel Mack <daniel@xxxxxxxxxx> > >>> > >>> kdbus is a system for low-latency, low-overhead, easy to use > >>> interprocess communication (IPC). > >>> > >>> The interface to all functions in this driver is implemented via ioctls > >>> on files exposed through a filesystem called 'kdbusfs'. The default > >>> mount point of kdbusfs is /sys/fs/kdbus. This patch adds detailed > >>> documentation about the kernel level API design. > >> > >> I have some details feedback on the contents of this file, and some > >> bigger questions. I'll split them out into separate mails. > >> > >> So here, the bigger, general questions to start with. I've arrived late > >> to this, so sorry if they've already been discussed, but the answers to > >> some of the questions should actually be in this file, I would have > >> expected. > >> > >> This is an enormous and complex API. Why is the API ioctl() based, > >> rather than system-call-based? Have we learned nothing from the hydra > >> that the futex() multiplexing syscall became? (And kdbus is an order > >> of magnitude more complex, by the look of things.) At the very least, > >> a *good* justification of why the API is ioctl()-based should be part > >> of this documentation file. > >> > >> An observation: The documentation below is substantial, but this API is > >> enormous, so the documentation still feels rather thin. What would > >> really help would be some example code in the doc. > >> > >> And on the subject of code examples... Are there any (prototype) > >> working user-space applications that exercise the current kdbus > >> implementation? That is, can I install these kdbus patches, and > >> then find a simple example application somewhere that does > >> something to exercise kdbus? > > > > If you run a 3.18 kernel, you can install kdbus.ko from our repository > > and boot a full Fedora system running Gnome3 with kdbus, given that > > you compiled systemd with --enable-kdbus (which is still > > experimental). No legacy dbus1 daemon is running. Instead, we have a > > bus-proxy that converts classic dbus1 to kdbus, so all > > bus-communication runs on kdbus. > > FWIW, we've been building a "playground" repository for the kernel > that contains this already for Fedora. If you have a stock Fedora 21 > or rawhide install, you can use: > > https://copr.fedoraproject.org/coprs/jwboyer/kernel-playground/ > > which has the kernel+kdbus and systemd built with --enable-kdbus > already. Easy enough to throw in a VM for testing. > > josh Yes thanks josh! Another addition, if kdbus is installed and loaded, you could also use systemd-nspawn to boot a full system (systemd compiled with --enable-kdbus) in a container [1], kdbusfs will be mounted in the container. There is also the busctl tool to query kdbus... http://www.freedesktop.org/wiki/Software/systemd/VirtualizedTesting/ -- Djalal Harouni http://opendz.org -- 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
