kdbus and Fedora

[Kay Sievers]

On Wed, May 6, 2015 at 11:45 AM, Harald Hoyer <harald at redhat.com> wrote:
> On 05.05.2015 20:43, Josh Boyer wrote:
>> On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer <harald at redhat.com> wrote:
>>> On 05.05.2015 19:50, Josh Boyer wrote:
>>>> Hi All,
>>>>
>>>> Harald and I were recently talking about kdbus and how it plays into
>>>> Fedora.  Right now, the kernel-playground COPR is carrying the kdbus
>>>> patches, but that isn't widely used and isn't included in a broad test
>>>> base. Obviously our distribution is heavily entwined with D-Bus and we
>>>> were looking to see if it was possible to help kdbus testing and
>>>> development by doing some kind of integration within Fedora itself.  I
>>>> promised Harald I would talk it over with the other Fedora kernel
>>>> maintainers and after a brief discussion we came up with the following
>>>> possible proposal.
>>>>
>>>> If Fedora were to carry kdbus in any form, the following things would
>>>> be required:
>>>>
>>>> 1) There would be a single canonical location to track kdbus
>>>> development.  After talking with Harald, that should be the upstream
>>>> tree that gregkh is using to submit patches.
>>>>
>>>> 2) Harald's team (systemd, etc) would commit to testing the system
>>>> both with and without kdbus active.  Obviously we do not want to
>>>> enforce reliance on something as core critical as kdbus while it is
>>>> still being actively developed upstream.  That could cause a lot of
>>>> deviation down the road and it isn't the aim here.
>>>>
>>>> 3) kdbus would only be carried in the rawhide branch until it is
>>>> merged upstream.  As a concrete example, if kdbus was not merged in
>>>> the upstream kernel at the time rel-eng creates the F23 branches, then
>>>> Fedora 23 will never get kdbus.  It will be carried in rawhide and
>>>> rawhide only until it's accepted upstream.  The maintainers actually
>>>> hope this does get merged but we want to make sure we are prepared to
>>>> drop this without causing too much trouble if needed.
>>>>
>>>> 4) After discussing a bit with the rest of the Fedora kernel
>>>> maintainers, we would carry an additional patch that would require
>>>> 'kdbus-enabled' to be specified before the kernel would allow kdbus to
>>>> be loaded (or similar mechanism).  This would focus the main testing
>>>> effort for all the default images to remain as they are today, while
>>>> easily allowing the plumbing layer developers access to kdbus for
>>>> their enablement testing.
>>>>
>>>> These conditions would hopefully help the Fedora kernel maintainers
>>>> avoid some of the pitfalls of carrying a large chunk of out of tree
>>>> code and if they're all met we feel fairly comfortable with doing
>>>> this.  We wanted to send this out for a bit wider discussion and
>>>> review before proceeding with it, and I agreed to start this thread so
>>>> here we are.
>>>>
>>>> Harald, does the above look like what you were envisioning when we
>>>> talked earlier?
>>>>
>>>> josh
>>>>
>>>
>>> Looks very good except for point 4, where we wanted to enable kdbus by default
>>> and have a "kdbus=0" command line option.
>>
>> Right, but that is actually counter-intuitive from the distro
>> perspective.  If we aren't going to ship kdbus in a release before
>> it's merged upstream, then you want all the regular default testing
>> that happens during that release's development to be done with what is
>> expected to be the default.  In most cases for now, that is likely to
>> be non-kdbus.
>>
>> An argument could be made that since we're dropping kdbus at the
>> Branched point if it isn't merged, there is time to test still but I'd
>> like to hear other's thoughts on that.
>
> One possibility is to enable kdbus by default until alpha phase.
> (-: Or make it alternate every two weeks or every reboot :-)

The userspace part requires "kdbus" to be given on the kernel command
line since the beginning of kdbus development. Without this specified,
the module will not be loaded, kdbus not activated by userspace, and
the dbus-1 daemon be used.

If the module is manually loaded later, it will not influence the
running system, but the kdbus kernel interface it is still usable for
the kdbus test programs, and for development it can also be used
inside a container. That's why we need to carry the enable switch in
userspace and not in the kernel module itself.

We should keep the explicit enabling in rawhide at least for a couple
of weeks, while we ask people to manually enable and run it on their
systems. If that works out well, we will discuss with the Fedora
kernel maintainers, if it might be reasonable to switch the default.
Does that make sense?

Anyway, thanks for your support. It will help us a lot if kdbus is in
rawhide and that way easy to enable by people to get better testing.

Thanks,
Kay