On Wed, 29 Oct 2014, Greg Kroah-Hartman wrote: > > > kdbus is a kernel-level IPC implementation that aims for resemblance to > > > the the protocol layer with the existing userspace D-Bus daemon while > > > enabling some features that couldn't be implemented before in userspace. > > > > I'd be interested in the features that can't be implemented in userspace > > (and therefore would justify existence of kdbus in the kernel). Could you > > please point me to such list / documentation? > > Lennart has given whole talks about this in the past, here's a recent > talk going into the details: > https://www.youtube.com/watch?v=HPbQzm_iz_k I think it's a reasonable expectation that kernel patch submissions should be reasonably self-contained though. We've always been very strict about pushing everybody to provide extensive cover letters, changelogs and explanations, so this shouldn't really be an exception, I think. > > It seems to me that most of the highlight features from the cover letter > > can be "easily" (for certain definition of that word, of course) > > implemented in userspace (vmsplice(), sending fd through unix socket, user > > namespaces, UUID management, etc). > > We have dbus in userspace today, but that requires extra copies of data, But we can do zero-copy between processess for quite some time already, so what exactly is the issue here? > and isn't easy, or even possible, to do some of the application-specific > bus logic that kdbus provides. I unfortunately have absolutely no idea what should I imagine here. > See the talk above for details, there are slides around somewhere with > just text that we can add to the cover letter if that will help out in > future spins of this patch series. I think that would be very helpful. Thanks. -- Jiri Kosina SUSE Labs -- 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
