Re: kdbus: to merge or not to merge?

Martin Steigerwald
2015-06-23T09:26:06Z

Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger:
> On Tue, Jun 23, 2015 at 8:41 AM, Greg KH <gregkh@linuxfoundation.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