Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753614AbbDOI45 (ORCPT ); Wed, 15 Apr 2015 04:56:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:32853 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbbDOI4p (ORCPT ); Wed, 15 Apr 2015 04:56:45 -0400 Date: Wed, 15 Apr 2015 10:56:41 +0200 From: Greg Kroah-Hartman To: Jiri Kosina Cc: Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415085641.GH16381@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 3801 Lines: 75 On Wed, Apr 15, 2015 at 12:33:30AM +0200, Jiri Kosina wrote: > On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote: > > > Yes, it's an unfortunate design, but one that we are all stuck with > > (think of it as having to implement code for horrid hardware that you > > have to get to work properly.) > > Greg, I personally consider this a rather defunct analogy. Broken hardware > comes from "outter space" we just have to live with somehow, and > eventually try to gradually improve by working with vendors (and you > yourself have of course made huge improvements in this very area). > > Linux userspace is coming, well, from Linux developers. The sole fact that > someone wrote a daemon that runs on Linux seems like a very poor > justification for sucking the daemon into kernel "because we have to live > with it". > Userspace has to live with it somehow (and eventually fix itself if > necessary), yes. Why should kernel just contribute to this "unfortunate > design" if it really isn't, in any way, obliged or forced to do so? I retract my "unfortunate design" statement, as Havoc pointed out exactly why that design is the way it is, and it makes sense to me. To quote the email that he wrote: The reason is that dbus views the world in a stateful way assuming that connections, and name ownership, can be tracked reliably. This is different from say http, and it's one reason that people used to Internet-oriented protocols find dbus strange. I'm one of those "people used to internet-oriented protocols", and I bet that almost all of us kernel developers also fall into that category, as the kernel for the most part, is one big tool to help implement those Internet-oriented protocols :) The very history of D-Bus, where it came from, who is now using it, what happened to all of the other proposed solutions in this area, is worth examining if you are interested in it. This type of protocol solves a real problem in this area, one that everyone has congregated on as the best-known solution for that issue. It's used everywhere, on servers, embedded systems, desktops, you name it. All languages have bindings for it, and it's the underpinning of a modern Linux stack. For us to somehow say that it's a "horible protocol" is terribly unfair, and unkind, to all of the people who have worked to make it the best possible solution for this problem space. And honestly, I don't have a better proposal. And I seriously doubt that anyone here does either. In the many years I've spent working on this, dbus has seemed to be odd, and strange, to the way that the kernel has normally worked, because it is. And that's not a bad thing, it's just different, and for us to support real needs and requirements of our users, is the requirement of the Linux kernel. Now if there are technical problems or insecurities in the proposed code submission, wonderful, please let me know and I'll be glad to work to address them. But let's just drop the whole "oooh, look, D-Bus is horrible looking, we can't support that!", is not a valid justification. And I'll defer back to the old AF_DBUS proposal, which was looked at from a technical point of view of the network developers who said that they didn't think that putting the D-Bus model into a network stack made any sense from a technical point of view, and outligned their objectsions. And they were right, hence this different proposal many years later based on their insight and suggestions. If you have objections like that, great, please let me know. 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/