Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932368AbbFWJiL (ORCPT ); Tue, 23 Jun 2015 05:38:11 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:34247 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753702AbbFWJiH convert rfc822-to-8bit (ORCPT ); Tue, 23 Jun 2015 05:38:07 -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:38:05 +0200 Message-ID: <10108356.DvbMMz3beW@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: <2043679.3XtbGfUgIP@merkaba> References: <2043679.3XtbGfUgIP@merkaba> 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: 5801 Lines: 118 Am Dienstag, 23. Juni 2015, 11:25:49 schrieb Martin Steigerwald: > 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.htm > > l > > > > * 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. Let me take some judgement out of what I wrote and have an attempt to describe instead: >From Lennart himself who on the other hand complains about what he perceives as (my wording from memory of his Google Plus post) 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/