linux-kernel - Re: kdbus: to merge or not to merge?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Jun 2015 19:20:27 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

On Wed, Jun 24, 2015 at 7:14 PM, Steven Rostedt <rostedt@...dmis.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/