kdbus and Fedora

[Harald Hoyer]

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.
> 
> josh
> 

One possibility is to enable kdbus by default until alpha phase.
(-: Or make it alternate every two weeks or every reboot :-)