Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756707AbbDOQko (ORCPT ); Wed, 15 Apr 2015 12:40:44 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:44277 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964965AbbDOQkk (ORCPT ); Wed, 15 Apr 2015 12:40:40 -0400 Date: Wed, 15 Apr 2015 18:40:33 +0200 From: Greg Kroah-Hartman To: Steven Rostedt 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: <20150415164033.GB25105@kroah.com> References: <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> <20150415154153.GD6801@home.goodmis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415154153.GD6801@home.goodmis.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2600 Lines: 53 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 -- 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/