Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932547AbbFWJ0G (ORCPT ); Tue, 23 Jun 2015 05:26:06 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:57696 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932499AbbFWJZx convert rfc822-to-8bit (ORCPT ); Tue, 23 Jun 2015 05:25:53 -0400 From: Martin Steigerwald To: Richard Weinberger Cc: Greg KH , Andy Lutomirski , Linus Torvalds , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack Subject: Re: kdbus: to merge or not to merge? Date: Tue, 23 Jun 2015 11:25:49 +0200 Message-ID: <2043679.3XtbGfUgIP@merkaba> User-Agent: KMail/4.14.7 (Linux/4.1.0-rc8-tp520-btrfstrim-pstatetrace+; KDE/4.14.2; x86_64; git-38b5d90; 2015-04-16) In-Reply-To: References: <20150623064140.GA18300@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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: 5302 Lines: 105 Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger: > On Tue, Jun 23, 2015 at 8:41 AM, Greg KH wrote: > >> The current state of uncertainty is problematic, I think. The kdbus > >> team is spending a lot of time making things compatible with kdbus, > >> and the latest systemd release makes kdbus userspace support > >> mandatory. > > > > I stopped here in this email, as this is just flat out totally wrong, > > and I don't want to waste my time trying to refute other totally wrong > > statements as that would just somehow give them some validation that > > they could possibly be correct. > > For the guys who not follow systemd development, this is the > announcement in question: > http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html > > * kdbus support is no longer compile-time optional. It is now > always built-in. However, it can still be disabled at > runtime using the kdbus=0 kernel command line setting, and > that setting may be changed to default to off, by specifying > --disable-kdbus at build-time. Note though that the kernel > command line setting has no effect if the kdbus.ko kernel > module is not installed, in which case kdbus is (obviously) > also disabled. We encourage all downstream distributions to > begin testing kdbus by adding it to the kernel images in the > development distributions, and leaving kdbus support in > systemd enabled. > > Now kdbus is opt-out instead of opt-in. > Although I didn't test it so far, systemd should work just fine if > kdbus is not present > as it can fall back to dbus. Andy, I think it was partly this what triggered your mail. I wrote a mail about asking for a careful review of dbus exactly due to this some days ago, but didn´t include any Ccs. In that I wrote: ------------------------------------------------------------------------- I hope you kernel developers will still review kdbus carefully as you did so far, instead of giving in to any downstream pressure by distros. It is exactly this attitude and this approach of systemd upstream that I feel uneasy about. Instead of humbly waiting and working towards having kdbus accepted to the kernel, systemd developers seem to use any means to create indirect pressure to have it included eventually. I hope that it will still be technical excellence as entry barrier for anything that goes into the kernel. Please note: I do not judge upon the technical quality of kdbus. I think others are more knowledgeable to do it. ------------------------------------------------------------------------- I think the move of systemd developers is able to create downstream pressure to include kdbus into the kernel and Andy´s mail is partly a reaction to that. I personally wouldn´t ask for it not to be included into the kernel, but I just ask for a careful review instead of giving in to any downstream pressure the move of systemd developers may trigger. But unlike Andy I did not review kdbus for technical quality. It seems that Andy has strong technical concerns about it. But you Greg, write that these are not correct without any explaination on why you think this is so. You outrightly write that these are invalid without any explaination at all. Greg, if you do not want any preemptive decision not to merge kdbus before your next pull request, I kindly also ask for for no preemptive decision to actually merge it then, as it may be included in Fedora or other distro kernels already. Having it in distros can be good for testing things, but it does not necessarily say anything about technical qualification of the patches for the upstream kernel. So no argument like in "but, look, its in the distros" in my view is enough reason to merge it into the upstream kernel. On the next time you do your pull request, if Andy or anyone else posts technical concerns, for a careful review process I think it is important that you or someone else actually addresses them instead of just telling that these are invalid (in your point of view!). Cause this is exactly again an attitude I found with systemd upstream. "I am right, you are wrong, go away". It is this kind of attitude – I have seen it on both sides of this discussion – that creates most of the friction and energy blockage and polarity around this topic. I tried to bring this up in systemd-devel once, but in the end I unsubscribed after having been called "being a dick" there. From Lennart himself who on the other hand whines about perceived rudeness in kernel community. So again I ask: What is it what you actually want to create? And how can you create it (instead of creating something, like this friction and energy blockage, that you probably didn´t want to create at all)? I ask this to anyone involved. Thank you, -- 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/