Re: kdbus and Fedora
On Wed, Jun 24, 2015 at 12:46 PM, Harald Hoyer har...@redhat.com wrote:
On 24.06.2015 17:17, Josh Boyer wrote:
On Wed, May 6, 2015 at 8:46 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobin...@gmail.com 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
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.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing
something that generates audit messages and those spewing to the
journal. This drives the load on my laptop up to 5-6 or so and
cpu
fans spinning.
I noticed this as well.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied
{ connectto } for pid=1086 comm=sedispatch
path=/run/dbus/system_bus_socket
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
Where should we report bugs for this work?
Hm, tough call. Perhaps against systemd unless it's a kernel oops?
I
would think systemd might need to set SELinux to permissive if it's
booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no
longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we
should just get labeled correctly in policy?
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
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.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing
something that generates audit messages and those spewing to the
journal. This drives the load on my laptop up to 5-6 or so and cpu
fans spinning.
I noticed this as well.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied
{ connectto } for pid=1086 comm=sedispatch
path=/run/dbus/system_bus_socket
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
Where should we report bugs for this work?
Hm, tough call. Perhaps against systemd unless it's a kernel oops? I
would think systemd might need to set SELinux to permissive if it's
booting in kdbus mode until kdbus works with SELinux upstream.
Harald?
josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Wed, 8 Jul 2015 10:32:53 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
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.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing
something that generates audit messages and those spewing to the
journal. This drives the load on my laptop up to 5-6 or so and cpu
fans spinning.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied
{ connectto } for pid=1086 comm=sedispatch
path=/run/dbus/system_bus_socket
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
Where should we report bugs for this work?
Thanks,
kevin
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
Hi
On Wed, Jul 8, 2015 at 8:39 PM, Eric Paris epa...@redhat.com wrote:
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
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.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing
something that generates audit messages and those spewing to the
journal. This drives the load on my laptop up to 5-6 or so and
cpu
fans spinning.
I noticed this as well.
I assume this happens only with kdbus=1 (and is unrelated to other
4.2-rc1 changes)? Any details on this are highly welcome.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied
{ connectto } for pid=1086 comm=sedispatch
path=/run/dbus/system_bus_socket
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
Where should we report bugs for this work?
(kdbus related bugs should be reported against systemd for now. If
it's a kernel oops, you might wanna prefer LKML and put us on CC).
Hm, tough call. Perhaps against systemd unless it's a kernel oops?
I
would think systemd might need to set SELinux to permissive if it's
booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no
longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we
should just get labeled correctly in policy?
This is the system bus socket of dbus-daemon. If kdbus is enabled,
it's not used by any systemd binary (they use kdbus directly). The
only exception is systemd-bus-proxyd which provides this socket
(replaces dbus-daemon) for backwards compatibility (proxy between
dbus1 and kdbus). This socket, though, is created by pid1 via a
.socket unit and bus-proxyd is socket activated.
As I cannot parse this selinux error, I hope someone with selinux
background can shed some light on this.
Thanks
David
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On 05.05.2015 20:43, Josh Boyer wrote: On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer har...@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 :-) ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Wed, May 6, 2015 at 11:45 AM, Harald Hoyer har...@redhat.com wrote: On 05.05.2015 20:43, Josh Boyer wrote: On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer har...@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 ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On 05/06/2015 09:57 AM, Amit Shah 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 ) 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 JBG ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
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 :-) Well the enable until alpha is basically what Josh was suggesting with the in rawhide until branching bit because we branch just before we freeze for Alpha. On the alternate weeks/reboot proposal... rawhide contains a fast moving kernel already I'm really not sure a revolving door approach would be good for user or kernel team's sanity or kdbus as a proposal. The proposal here was to make it easier to be tested so getting it in the default installed kernel is clearly the biggest obstacle in this regard. I think maybe do the rest in two phases: 1) get it landed but leave it disabled by default 2) based on feedback of users then review whether enabling it by default is worthwhile. It's then easy to review and move forward. Ultimately I think we need the default to be what is going to be the default for the release it's being built for because otherwise the testing is useless for the distribution as a whole. Peter ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobin...@gmail.com 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. As soon as I see the refreshed patchset I'll look at getting them in. josh ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On 05.05.2015 20:28, Harald Hoyer 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. CC'ing the kdbus folks... btw, currently the kdbus module is only loaded by systemd, if you specify kdbus on the kernel command line. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer har...@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 ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kdbus and Fedora
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. CC'ing the kdbus folks... ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
