Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932568AbbDUQy6 (ORCPT ); Tue, 21 Apr 2015 12:54:58 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:33643 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932225AbbDUQy5 (ORCPT ); Tue, 21 Apr 2015 12:54:57 -0400 MIME-Version: 1.0 In-Reply-To: <552EA700.7000200@gmail.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <20150414193533.GF889@ZenIV.linux.org.uk> <20150414194348.GA7540@kroah.com> <552EA700.7000200@gmail.com> Date: Tue, 21 Apr 2015 13:54:54 -0300 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: Diego Viola To: Austin S Hemmelgarn Cc: Greg Kroah-Hartman , Al Viro , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2116 Lines: 52 I'd like to see D-Bus in the kernel (kdbus), if that's going to make D-Bus faster. See this application taking 15 seconds to start just because D-Bus is too slow. https://bugs.kde.org/show_bug.cgi?id=342682 Hopefully kdbus solves problems such as this one. Diego On Wed, Apr 15, 2015 at 2:59 PM, Austin S Hemmelgarn wrote: > On 2015-04-14 15:43, Greg Kroah-Hartman wrote: >> >> On Tue, Apr 14, 2015 at 08:35:33PM +0100, Al Viro wrote: >>> >>> On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman wrote: >>> >>>>> I agree. You've sent a pull request for an unfortunate design. I >>>>> don't think that unfortunate design belongs in the kernel. If it says >>>>> in userspace, then user programmers could potentially fix it some day. >>>> >>>> >>>> You might not like the design, but it is a valid design. Again, we >>>> don't refuse to support hardware that is designed badly. Or support >>>> protocols we don't necessarily like, that's not the job of a kernel or >>>> operating system. >>> >>> >>> And no, "the sole consumer of that API knows better, so bend over" is not >>> a good idea. We have shitloads of examples when single-consumer APIs >>> turned into screaming horrors; taking that in over the objections to API >>> design, merely on "they do it that way, who the hell we are to say they >>> are wrong?" is insane. >> >> >> Again, in this domain, the design is sound. So much so that everyone >> who works in that area moved toward it (KDE, Qt, Go, etc.) We might not >> think it makes sense, and it did take me a while to wrap my head around >> it, but to call it "crap" is unfair, sorry. >> > > The reason that 'everyone who works in this area' adopted is not as much > that the design is sound (I'm not arguing whether it is or isn't in this > case) as it is that none of them could come up with anything better. > -- 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/