From: Martin Steigerwald <martin@lichtvoll.de>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Herrmann <dh.herrmann@gmail.com>,
Djalal Harouni <tixxdz@opendz.org>,
Havoc Pennington <havoc.pennington@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Tom Gundersen <teg@jklm.no>, Daniel Mack <daniel@zonque.org>
Subject: Re: kdbus: to merge or not to merge?
Date: Tue, 23 Jun 2015 11:25:49 +0200 [thread overview]
Message-ID: <2043679.3XtbGfUgIP@merkaba> (raw)
In-Reply-To: <CAFLxGvxn6_ia3XqjDwJ9cTig_b4u_5zgiu4q9J=U615qqyO=gg@mail.gmail.com>
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
next prev parent reply other threads:[~2015-06-23 9:26 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 6:06 kdbus: to merge or not to merge? Andy Lutomirski
2015-06-23 6:31 ` Andy Lutomirski
2015-06-23 6:41 ` Greg KH
2015-06-23 7:22 ` Richard Weinberger
2015-06-23 9:25 ` Martin Steigerwald [this message]
2015-06-23 9:38 ` Martin Steigerwald
2015-06-23 15:07 ` Andy Lutomirski
2015-06-25 2:14 ` Steven Rostedt
2015-06-25 2:20 ` Linus Torvalds
2015-06-25 6:01 ` Martin Steigerwald
2015-06-25 6:05 ` Martin Steigerwald
2015-06-25 13:34 ` Theodore Ts'o
2015-06-25 14:03 ` Martin Steigerwald
2015-06-23 9:12 ` Borislav Petkov
2015-07-08 13:54 ` Pavel Machek
2015-07-09 8:39 ` Geert Uytterhoeven
2015-07-09 10:29 ` Joe Perches
2015-07-09 10:57 ` Geert Uytterhoeven
2015-07-09 11:36 ` Pavel Machek
2015-06-23 23:19 ` Linus Torvalds
2015-06-24 0:52 ` Andy Lutomirski
2015-06-24 8:05 ` Ingo Molnar
2015-06-24 10:41 ` Eric W. Biederman
2015-06-24 10:46 ` Martin Steigerwald
2015-06-24 13:18 ` Ingo Molnar
2015-06-24 17:39 ` David Lang
2015-06-24 18:41 ` Eric W. Biederman
2015-06-24 18:50 ` Martin Steigerwald
2015-06-24 19:12 ` David Lang
2015-06-25 7:57 ` Geert Uytterhoeven
2015-06-25 15:26 ` Steven Rostedt
2015-06-25 6:31 ` Greg KH
2015-06-25 6:48 ` David Lang
2015-06-25 7:47 ` Ingo Molnar
2015-06-25 7:51 ` Ingo Molnar
2015-06-24 11:43 ` Martin Steigerwald
2015-06-24 13:27 ` Ingo Molnar
2015-06-24 9:55 ` Alexander Larsson
2015-06-24 14:38 ` Andy Lutomirski
[not found] ` <CAHr-LrYWNwv6_YLoP-B3duQ1QsjPiTiaEnjBQ7j2brPMeTgA3A@mail.gmail.com>
[not found] ` <CALCETrW3F6YP_H1oRJa47f1DT7B35OubhJYSnq0U-_GmFQHNOA@mail.gmail.com>
2015-06-24 17:11 ` Alexander Larsson
2015-06-24 19:43 ` Andy Lutomirski
2015-06-24 20:45 ` Alexander Larsson
2015-08-03 23:02 ` Andy Lutomirski
2015-08-04 8:58 ` David Herrmann
2015-08-04 13:46 ` Linus Torvalds
2015-08-04 14:09 ` David Herrmann
2015-08-04 14:47 ` Andy Lutomirski
2015-08-05 0:18 ` Andy Lutomirski
2015-08-06 7:06 ` Daniel Mack
2015-08-06 15:27 ` Andy Lutomirski
2015-08-06 17:24 ` Daniel Mack
2015-08-05 7:10 ` David Herrmann
2015-08-05 20:11 ` Andy Lutomirski
2015-08-06 8:04 ` David Herrmann
2015-08-06 8:25 ` Martin Steigerwald
2015-08-06 15:21 ` Andy Lutomirski
2015-08-06 18:14 ` Daniel Mack
2015-08-06 18:43 ` Andy Lutomirski
2015-08-07 14:40 ` Daniel Mack
2015-08-07 15:09 ` Andy Lutomirski
[not found] ` <CA+55aFxDLt-5+=xXeYG4nJKMb8L_iD9FmwTZ2VuughBku-mW3g@mail.gmail.com>
2015-08-09 19:00 ` Greg Kroah-Hartman
2015-08-09 22:11 ` Daniel Mack
2015-08-10 2:10 ` Andy Lutomirski
2015-08-10 17:04 ` Linus Torvalds
2015-08-10 2:48 ` David Lang
2015-08-07 15:37 ` cee1
-- strict thread matches above, loose matches on Subject: below --
2015-07-01 0:03 Kalle A. Sandstrom
2015-07-01 16:51 ` David Herrmann
2015-07-06 21:18 ` Kalle A. Sandstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2043679.3XtbGfUgIP@merkaba \
--to=martin@lichtvoll.de \
--cc=daniel@zonque.org \
--cc=dh.herrmann@gmail.com \
--cc=ebiederm@xmission.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=havoc.pennington@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=richard.weinberger@gmail.com \
--cc=teg@jklm.no \
--cc=tixxdz@opendz.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox