On 24.06.2015 17:17, Josh Boyer wrote:
> On Wed, May 6, 2015 at 8:46 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>> On Wed, May 6, 2015 at 8:38 AM, Peter Robinson <pbrobinson(a)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