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. >> As soon as I see the refreshed patchset I'll look at getting them in. > > The kdbus developers have indicated they believe the code is ready and > that there should not be any ABI breaks at this point. I'm working > with them to make sure we're all set, but assuming everything holds > from before we will likely look at adding the code to rawhide soon. > > josh > _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
