Message-ID: <2043679.3XtbGfUgIP@merkaba>
Date:	Tue, 23 Jun 2015 11:25:49 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	Richard Weinberger <richard.weinberger@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.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?

Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger:
> On Tue, Jun 23, 2015 at 8:41 AM, Greg KH <gregkh@...uxfoundation.org> 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists