Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932254AbbDOPmM (ORCPT ); Wed, 15 Apr 2015 11:42:12 -0400 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.225]:33353 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754353AbbDOPl5 (ORCPT ); Wed, 15 Apr 2015 11:41:57 -0400 Date: Wed, 15 Apr 2015 11:41:53 -0400 From: Steven Rostedt To: Greg Kroah-Hartman Cc: Borislav Petkov , Richard Weinberger , Andy Lutomirski , Al Viro , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415154153.GD6801@home.goodmis.org> References: <20150413202233.GR889@ZenIV.linux.org.uk> <20150415084812.GG16381@kroah.com> <552E28C2.8070409@nod.at> <20150415092034.GA17680@kroah.com> <20150415092149.GB2310@pd.tnic> <20150415092713.GA17898@kroah.com> <20150415094410.GB2282@pd.tnic> <20150415114036.GB19274@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415114036.GB19274@kroah.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2770 Lines: 52 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/