On 05.05.2015 20:43, Josh Boyer wrote: > On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer <harald@xxxxxxxxxx> 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 :-) _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
