Message-ID: <20150415154153.GD6801@home.goodmis.org>
Date:	Wed, 15 Apr 2015 11:41:53 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Borislav Petkov <bp@...en8.de>,
	Richard Weinberger <richard@....at>,
	Andy Lutomirski <luto@...capital.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 01:40:36PM +0200, Greg Kroah-Hartman wrote:
> 
> You have to trust someone to help make your system work together in a
> unified way.  If you can't trust your distro's engineers, then either
> start your own distro, or only run busybox on top of a kernel.  You
> really don't have much other "choice" than that :)

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.

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.

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.

This isn't a case of Republicans vs Democrats pushing a health care system within
a window that was rushed. Now the US has a health care system that somewhat works
but due to politics its not being fixed (the ABI is solidified). I don't want
to have the same thing with kdbus. We are technical people here, lets solve it
with a technical solution, and not rush into things. dbus works today, what's
the rush to put something into the kernel that must be supported forever. Lets
make sure we do it right.

I'm serious about my Linux Plumbers proposal. If you can make it, and get the dbus
authors there too, and hopefully, Andy, Al and Eric can make it too. We should
really sit down and talk about it. Any other kernel developer that wants to
participate should, as a prerequisite, sit down and write a dbus interface, such
that they have an idea of how it works. I plan to. And I hope that I can learn
more about the interface and productively join in this discussion.

I'm willing to moderate the kdbus microconference. I think I'll add it now.

Thoughts?

-- Steve

--
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/

Powered by blists - more mailing lists