Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756444AbbDOSE7 (ORCPT ); Wed, 15 Apr 2015 14:04:59 -0400 Received: from smtprelay0098.hostedemail.com ([216.40.44.98]:36512 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756378AbbDOSEy (ORCPT ); Wed, 15 Apr 2015 14:04:54 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 40,2.5,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::::::::::,RULES_HIT:41:355:379:421:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1535:1543:1593:1594:1605:1711:1730:1747:1777:1792:2393:2553:2559:2562:2692:2693:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:5007:6117:6119:6261:6742:7875:7903:7974:8531:10011:10400:10450:10455:10848:10967:11232:11658:11914:12050:12219:12517:12519:12663:12740:13095:13137:13150:13161:13229:13230:13231:13618:14039:14096:14097:19904:19999:21067:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:1:0 X-HE-Tag: rod94_d583d15f782d X-Filterd-Recvd-Size: 5557 Date: Wed, 15 Apr 2015 14:04:50 -0400 From: Steven Rostedt To: Greg Kroah-Hartman 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: <20150415140450.3685cb56@gandalf.local.home> In-Reply-To: <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> <20150415173145.GA26146@kroah.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3921 Lines: 96 On Wed, 15 Apr 2015 19:31:45 +0200 Greg Kroah-Hartman wrote: > > 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? :) Exactly, but if you invite those people, and say "hey, here's your chance to set us straight" maybe they'll come. I would. But give them a few weeks notice, so that they can study what's out there. > > 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 We are all making our own little exaggerated metaphors. ;-) > 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. No, but people seems to be worried about the complexity. If everyone understands that there's no other choice but to have it complex (like RCU is), then everyone will be fine with it. But right now, people are questioning why it needs to be complex. But we need more people to spend time on it to make sure it does. > > 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 still need to play with the code and see exactly what it does. What goes into the kernel needs to be the raw interface only. Everything else should be in a library that takes care of the details. Is that what is here? > > 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 this what is being proposed (again, I need to go back and read the original change log. I did it once, but mostly forgot what was in it). > > > 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. Well, there's been a few minor things that have been pointed out (the locking), and having something as small as that take place during a merge window, to me, would be cause to wait another merge window. > > > 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. But there are still complaints about it. Perhaps people are just noticing. We are all busy, and nobody (but perhaps Andrew Morton and Jon Corbet) reads every LKML message. It's now getting more eyes. That's a good thing. I'd like more time to play with it so that I can understand why exactly it needs to go in as you say it does. -- 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/