Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754193AbbDNUMB (ORCPT ); Tue, 14 Apr 2015 16:12:01 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:50506 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752958AbbDNULw convert rfc822-to-8bit (ORCPT ); Tue, 14 Apr 2015 16:11:52 -0400 From: Martin Steigerwald To: Greg Kroah-Hartman Cc: Al Viro , Borislav Petkov , 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 Date: Tue, 14 Apr 2015 22:11:50 +0200 Message-ID: <1543881.u9EccR8V4Q@merkaba> User-Agent: KMail/4.14.7 (Linux/4.0.0-tp520-btrfs-trim+; KDE/4.14.2; x86_64; git-b05922a; 2015-04-12) In-Reply-To: <20150414194804.GB7540@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150414194004.GG889@ZenIV.linux.org.uk> <20150414194804.GB7540@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3674 Lines: 78 Am Dienstag, 14. April 2015, 21:48:04 schrieb Greg Kroah-Hartman: > On Tue, Apr 14, 2015 at 08:40:04PM +0100, Al Viro wrote: > > On Tue, Apr 14, 2015 at 09:32:29PM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Apr 14, 2015 at 09:24:29PM +0200, Borislav Petkov wrote: > > > > On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman wrote: > > > > > You might not like the design, but it is a valid design. Again, > > > > > we > > > > > don't refuse to support hardware that is designed badly. > > > > > > > > Yeah except the small difference that unlike this, we can't change > > > > hardware. > > > > > > And we can't change the design/implementation of many things, again, > > > it's not the kernel's job to prevent something, just because we > > > don't > > > like the RFC, from being accepted. > > > > Translate, please. What exactly will be prevented by NAK on your Fine > > Piece Of Software? Not dbus working as it does, surely? > > I don't understand. You can not like the D-Bus model (and accordingly > the X11 model), but to prevent users from wanting to use it in a more > secure, and faster way by implementing it like we have seems very odd to > me. > > It's not going to stop anything from working, it's just going to stop > some programs from being able to do things they really want to do (see > the first email for examples.) > > Yes, we could make this live outside the kernel tree, but that's not the > way we work anymore. We merge things that are useful, that match our > security and coding requirements, and are going to be maintained by > people we trust. To have the only major objection be "we don't like > the way the protocol is designed because we know better, sorry", isn't > ok at all. Greg, I think I understood Al here. dbus as it is used in KDE, GNOME, network-manager, systemd, you name it does work. Not merging kdbus will not break it. So the ones who want to see kdbus in kernel want to do something better or differently like it is currently done in dbus. And yes, I have seen the presentations about the benefits of having dbus in the kernel. But if thats the case, what I think Al asks for a *new* kernel component is a sound design that does not repeat any flaws from the original design as the original design is no hardware that cannot be changed anymore after production. And to whether the design of kdbus is sound there seem to be strong different oppinions about it. I think it is important to accept that and go from there. On the other hand, if you do things differently enough from the way userspace dbus is doing it in order to have such a sound design, it may be necessary to adapt all applications to it. But since kdbus is not yet in the kernel officially this would not violate the "we never ever break userspace" rule, cause the kernel obviously doesn?t guarantee the stability of the current userspace dbus API, cause it doesn?t yet have such an API at all. But if kdbus goes in, it has, and then it needs to guarantee it until this "never break userspace" rule is changed, *if* ever. And also: Even if the kernel API is different in order to be sound, it may be possible to adapt userspace dbus to use it to improve upon some of its current flaws so that applications using it do not need to be changed at all. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/