>>> On 25.08.17 at 17:49, <george.dun...@citrix.com> wrote: > On 08/25/2017 02:44 PM, Jan Beulich wrote: >>>>> On 25.08.17 at 15:00, <aisa...@bitdefender.com> wrote: >>> On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: >>>>> >>>>>> >>>>>>> >>>>>>> On 17.08.17 at 13:50, <aisa...@bitdefender.com> wrote: >>>>> --- a/xen/common/monitor.c >>>>> +++ b/xen/common/monitor.c >>>>> @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct >>>>> xen_domctl_monitor_op *mop) >>>>> domain_pause(d); >>>>> d->monitor.guest_request_sync = mop->u.guest_request.sync; >>>>> d->monitor.guest_request_enabled = requested_status; >>>>> + d->arch.monitor.guest_request_userspace_enabled = mop- >>>>>> u.guest_request.allow_userspace; >>>> This breaks the build on ARM. >>> There are 2 solutions, I can move the case in x86/monitor.c in >>> the arch_monitor_domctl_event function or I can make a arch specific >>> function that does the assignment in the x86 case and does nothing in >>> the arm case. What approach do you prefer? >> >> That's a question to the maintainers of that code. What I care >> about is that patches touching common code please are at least >> build-checked on the other architecture before submission. > > I don't think this is a reasonable requirement. That's what push gates > (and Travis) are for.
Hmm, I can see your way of thinking, but to me (doing an ARM build test if I don't forget it before pushing) it's a waste of time to apply a patch only to then find it breaks the build and needs reverting. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
