kdbus and Fedora

[Josh Boyer]

On Wed, Jun 24, 2015 at 12:46 PM, Harald Hoyer <harald at redhat.com> wrote:
> On 24.06.2015 17:17, Josh Boyer wrote:
>> On Wed, May 6, 2015 at 8:46 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
>>> On Wed, May 6, 2015 at 8:38 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>>>>> On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
>>>>>>
>>>>>>> One possibility is to enable kdbus by default until alpha phase.
>>>>>>
>>>>>> The problem with that is all systemd testing is useless once we're out
>>>>>> of Alpha.  Similar things have happened in the past.
>>>>>>
>>>>>
>>>>> Which is precisely the point.
>>>>>
>>>>> Alpha needs to be released with this applied and enabled  to be useful to
>>>>> anybody.  ( and this needs to be applied and enabled up to that point )
>>>>
>>>> Only if it's being proposed as a feature of that release and to be
>>>> default, this isn't part of the above proposal.
>>>>
>>>>> Around that point 4.3 should have been released ( or about to be released )
>>>>> and either kdbus will be included or it should be clear that it will be
>>>>> included in 4.4 or never but surrounding bugs around the changes to Dracut
>>>>> implementing integration with kdbus will need to have started to receive
>>>>> wider exposure and tested and hopefully have most bugs flushed out otherwise
>>>>> you will be caught in spiral of delays if the intent is to include atleast
>>>>> Dracut with kdbus/integration changes in RHEL 8
>>>>
>>>> I think we're getting a bit ahead of ourselves, the proposal is
>>>> including it in the mainline Fedora kernel to enable easier testng,
>>>> and anything outside of Fedora isn't really our problem when we're
>>>> looking at rawhide TBH.
>>>
>>> Well, rawhide and rawhide only so it does play into what happens at
>>> branch time.  But yes, I think the proposal seems to cover this well
>>> enough and we can worry about it more when we come to that point.
>>>
>>>> Let's get patches in to enable it be more easily tested first...
>>>
>>> I'm waiting on the next posting of them before we bring them in.  It
>>> sounds like the proposed item 4 is already covered by the "kdbus"
>>> mechanism that systemd looks for so as long as that doesn't change, I
>>> think we're OK.
>>
>> Of course, the systemd mechanism changed.  Upstream now builds the
>> kdbus code in and requires kdbus=0 on the command line to disable it.
>> If I understand correctly, systemd should fall back to userspace dbus
>> if that is specified or if the kdbus.ko module is missing.
>>
>> Harald, given one of the conditions for carrying this was testing both
>> kdubs and non-kdbus setups, is your team prepared to do that with the
>> change in place in upstream systemd now?
>>
>
> systemd.spec in fedora has the configure options "--disable-kdbus", which means
> "do not connect to kdbus by default".
>
> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/bus-util.c#n2031
>
> bool is_kdbus_wanted(void) {
> …
> #ifdef ENABLE_KDBUS
>         const bool configured = true;
> #else
>         const bool configured = false;
> #endif
> …
>         if (get_proc_cmdline_key("kdbus", NULL) > 0)
>                 return true;
>
>         r = get_proc_cmdline_key("kdbus=", &value);
>         if (r <= 0)
>                 return configured;
>
>         return parse_boolean(value) == 1;
>
>
>
> So, I would say we are good to go. Default is "off", and it can be enabled with
> "kdbus" or "kdbus=1" on the kernel command line.

I just pushed this to git and started a build.  It will be in rawhide
tomorrow with the 4.2.0-0.rc1.git2.1 kernel.  (I was waiting for rc1
before adding it.)

I did test both with and without kdbus=1 and both worked at least from
a boot standpoint.  The initramfs on an install lacks the kdbus
module, so it needs to be rebuilt if one wishes to use kdbus.

josh