Re: [GIT PULL] kdbus for 4.1-rc1

[Richard Weinberger <richard@nod.at>]

Am 15.04.2015 um 11:20 schrieb Greg Kroah-Hartman:
> On Wed, Apr 15, 2015 at 11:00:50AM +0200, Richard Weinberger wrote:
>> Am 15.04.2015 um 10:48 schrieb Greg Kroah-Hartman:
>>> On Wed, Apr 15, 2015 at 08:54:07AM +0200, Richard Weinberger wrote:
>>>> On Wed, Apr 15, 2015 at 3:36 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>>> We had been there before.  To paraphrase another... meticulously honorable
>>>>>> person, "if you didn't want something relied upon, why have you put it into the
>>>>>> kernel?" Said person is on the record as having no problem whatsoever with
>>>>>> adding dependencies to the bottom of userland stack.
>>>>>
>>>>> It appears that, if kdbus is merged, upstream udev may end up requiring it:
>>>>>
>>>>> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>>>>
>>>> Why so surprised?
>>>> kdbus will be a major hard-dependency for every non-trivial userland.
>>>> Like cgroups...
>>>
>>> Maybe because things like cgroups, and kdbus in the future, solves a
>>> need that the developers in that area have to solve problems and
>>> provide functionality that their users require?
>>
>> I agree that a high level bus is needed and dbus is not perfect.
>> But this does not mean that we need a in-kernel dbus in any case.
> 
> So what do you propose to solve the issues presented in my original
> email about the usecases that this code addresses?
> 
>>> Look, us kernel developers only work on one huge, multithreaded, global
>>> state binary.  Our experience in multi-application interactions with
>>> shared state and permission requirements is usually quite limited.  If
>>> you don't trust the developers of those programs outside the kernel,
>>> don't use them, there are still distros out there that don't require
>>> them.
>>
>> We're all forced to use cgroups, systemd, udev unless we want to have busybox
>> as userland. That's a fact.
> 
> Is that a problem?
> 
>> systemd and its dependencies are not a bad thing per se.
>> But we have to be very sure that new hard-dependencies are
>> in well shape before we push them into the kernel.
> 
> That's fine, and normal, and I expect it.  But please provide technical
> reasons why the proposal is not acceptable, like Andy has done in this
> thread.

I did not state that the proposal is not acceptable.
My statement was that we have to be well aware of the fact that
we will be forced to use kdbus in future as it will become a dependency.

Some developers on IRC said they don't care about kdbus at all as long they
can disable it. This is wrong, we have to use it. And that is fine.
But we're all have be aware of the implications. kdbus will be ABI.

Thanks,
//richard