Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756397AbbDOSE4 (ORCPT ); Wed, 15 Apr 2015 14:04:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33807 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752252AbbDOSEs (ORCPT ); Wed, 15 Apr 2015 14:04:48 -0400 Message-ID: <552EA83D.6080708@redhat.com> Date: Wed, 15 Apr 2015 14:04:45 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Austin S Hemmelgarn , Greg Kroah-Hartman , Al Viro CC: 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 Subject: Re: [GIT PULL] kdbus for 4.1-rc1 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> In-Reply-To: <552EA700.7000200@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2400 Lines: 50 On 04/15/2015 01: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. They are smart people, and I would not underestimate the usefulness of the user space API (above the dbus library) that they came up with. That does not mean the actual in-kernel implementation needs to follow the same design criteria. It may make sense to have part of the implementation in kernel space, part in user space, and allow the userspace part to be switched out to accommodate other protocols over the same in-kernel bus... Moving some of the policy bits into a user space daemon may make sense. Storing messages that cannot be delivered right now in user space could make sense, too. -- 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/