Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756571AbbDORb5 (ORCPT ); Wed, 15 Apr 2015 13:31:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45653 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753586AbbDORbt (ORCPT ); Wed, 15 Apr 2015 13:31:49 -0400 Date: Wed, 15 Apr 2015 19:31:45 +0200 From: Greg Kroah-Hartman To: Steven Rostedt Cc: One Thousand Gnomes , Richard Weinberger , Andy Lutomirski , Al Viro , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , 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: <20150415173145.GA26146@kroah.com> References: <8738434yjk.fsf@x220.int.ebiederm.org> <20150413194217.GA10837@kroah.com> <20150413202233.GR889@ZenIV.linux.org.uk> <20150415084812.GG16381@kroah.com> <20150415122555.74258d63@lxorguk.ukuu.org.uk> <20150415154551.GE6801@home.goodmis.org> <20150415163520.GA25105@kroah.com> <20150415130649.6f9ab20f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415130649.6f9ab20f@gandalf.local.home> 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: 3630 Lines: 83 On Wed, Apr 15, 2015 at 01:06:49PM -0400, Steven Rostedt wrote: > On Wed, 15 Apr 2015 18:35:20 +0200 > Greg Kroah-Hartman wrote: > > > > > I suggest that we can do this at Linux Plumbers, and then follow up at > > > Kernel Summit, for those that can (or wont) attend plumbers. > > > > I really doubt this will work for Plumbers, sorry. And technical things > > don't work well, if at all, at Kernel Summit. > > > > We have had meetings about this at the past two Plumbers conferences, > > where none of these things came up (i.e. dislike of the D-Bus model). > > But were the people that are not liking it at those conference sessions? People who don't like a topic, usually go to a session about it, why would they? :) > > I'll be glad to discuss this at both places, but let's try to work > > through the technical things through email, as really, that's the best > > place for it. > > > > Al just proved this by pointing out some issues to be resolved (RW lock > > only used as a W lock, odd atomic values and locking without documenting > > the lifecycles, etc.) And that's the way this is supposed to work, > > nothing new/different here that I can see. > > But you are missing one of the complaints that I'm reading from > people. The proposed ABI is too complex. Do we really want to jump into > having to support another tty layer? Don't make idle comments, the tty layer is far more complex and larger than the kdbus code, with much nastier issues and problems. And we handle that just fine :) As far as the "support" issue, we have 4 people who are all experienced, senior kernel developers who are signed up to maintain this. There's more experience here for this one MAINTAINERS entry per line of code than I have seen in quite some time. Are people somehow worried that all 4 of us are going to run away? Do people not trust the 4 of us to stick around and maintain this and deal with any issues found for the next few decades? If so, please let us know, as it seems like people feel we are dumping this code on them to maintain, which is anything but true. > One thing that I think may be really worth doing is that everyone on > this thread that has not yet done so, write a simple dbus application > to try to understand its design. Break it down to the requirements that > are needed, and discuss that. I've done that, it's hard, use the gdbus interface instead, it makes your life much easier. I'll again refer to ALSA here, no one writes a "raw" ALSA program, they all use the library to interact with the kernel. Do that here, there are wonderful dbus libraries out there, for all languages. Use them instead. > Is there a reason that this patch must go in this merge window? What makes this merge window any different from any other? Again, I explained why I asked it to be merged at this point in time. If people have technical issues with it, I'll be more than glad to work them out and merge it later, there's no "hard and fast deadline" anyone is asking for here. > Having something this controversial take place during the merge window > suggests its a bit premature to push in now. "take place"? Have you been ignoring these patches posted numerous times for many months? This is the point in time to ask for code to be merged, just like any other code, nothing is special here. 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/