Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751962AbbFYCUe (ORCPT ); Wed, 24 Jun 2015 22:20:34 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:35884 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750903AbbFYCU2 (ORCPT ); Wed, 24 Jun 2015 22:20:28 -0400 MIME-Version: 1.0 In-Reply-To: <20150625021447.GA6837@home.goodmis.org> References: <20150623064140.GA18300@kroah.com> <20150625021447.GA6837@home.goodmis.org> Date: Wed, 24 Jun 2015 19:20:27 -0700 X-Google-Sender-Auth: GXy4dGurAq-LLHxMLLvnZd1q0kY Message-ID: Subject: Re: kdbus: to merge or not to merge? From: Linus Torvalds To: Steven Rostedt Cc: Andy Lutomirski , Richard Weinberger , Greg KH , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack 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: 1584 Lines: 33 On Wed, Jun 24, 2015 at 7:14 PM, Steven Rostedt wrote: > > I don't think it will complicate things even if the API changes. The distros > will have to deal with that fall out. Mainline only cares about its own > regressions. But any API changes would only be done for good reasons, and give > the distros an excuse to fix whatever was done wrong in the first place. I don't think that's true. Realistically, every single kernel developer tends to work on a machine with some random distro. If that developer cannot compile his own kernel because his distro stops working, or has to use some "kdbus=0" switch to turn off the kernel kdbus and (hopefuly) the distro just switches to the legacy user mode bus, then for that developer, merging and enabling incompatible kdbus implementation is basically a regression. We've seen this before. We end up stuck with the ABI of whatever user land applications. It doesn't matter where that ABI came from. I do agree that distro's that want to enable kdbus before any agreed version has been merged would get to also act as guinea pigs and do their own QA, and handle fallout from whatever problems they encounter etc. That part might be good. But I don't think we really end up having the option to make up some incompatible kdbus ABI after-the-fact. Linus -- 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/