lkml.org 
[lkml]   [2015]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kdbus: to merge or not to merge?
Date
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 <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.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


\
 
 \ /
  Last update: 2015-06-23 12:01    [W:0.150 / U:1.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site