On Wed, Jun 24, 2015 at 12:46 PM, Harald Hoyer <harald@xxxxxxxxxx> wrote: > On 24.06.2015 17:17, Josh Boyer wrote: >> On Wed, May 6, 2015 at 8:46 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >>> On Wed, May 6, 2015 at 8:38 AM, Peter Robinson <pbrobinson@xxxxxxxxx> 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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
