Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Apr 15, 2015 at 11:41:53AM -0400, Steven Rostedt wrote:
> 
> And obviously there is a lack of trust. And once kdbus is in, we must use
> it, or support our own distro where we just do not have the time.

Just like cgroups, and ftrace :)

> Personally, I'm fine with getting something in that will help userspace
> tools work better. The issue I see, mostly from the side lines as I haven't
> totally submerged myself into the dbus protocol (I think I should spend
> some time to do just that), this is going too fast. Once it is in the kernel,
> whatever ABI we expose is locked in stone. There's no changing it. We need
> to make sure that this is well thought out. People seem to be of the impression
> that the current dbus design has flaws, but because everything relies on it
> we must still push it into the kernel because it mimics what is out there
> in user space. I disagree.

"fast"?  Are you kidding me?  This stuff has been under active, public,
development for over two years.  We have been posting public patches,
asking for review and comments for _months_ now.  Given that there were
no more specific review comments on the patch set, and its success in
linux-next for almost the entire 4.0 development cycle, I asked it to be
merged.

I don't know too many other kernel features/drivers that have taken this
long, or done this "slowly", do you?

> As others have said. We do not need to follow the dbus design. If we can supply
> a better transport layer than what the kernel supplies today, then tools will
> eventually merge to it away from dbus. Perhaps the kernel can supply just enough
> to have dbus improve its speed, but not with the entire complex solution that
> kdbus is presenting today.

I originally thought this would work too.  8 months of work later, I was
proven wrong, that will not work.  Or it imposes too much additional
work on userspace that really makes no sense at all.  The in-kernel code
isn't a lot (again, 13k lines, smaller than almost all of the drivers
you are using today on an individual basis)  It's also really fast, but
with benchmarks, David and Andy have found some minor bottlenecks that
can make things faster.

Yes it seems complex, but read the documentation to get an idea of what
is happening here.  I think you will get a better appreciation of what
is going on.

thanks,

greg k-h