On Fri, Feb 6, 2015 at 3:20 PM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 06.02.15 at 14:10, <tamas.leng...@zentific.com> wrote: >> On Wed, Feb 4, 2015 at 10:47 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 29.01.15 at 22:46, <tamas.leng...@zentific.com> wrote: >>>> --- a/xen/common/Makefile >>>> +++ b/xen/common/Makefile >>>> @@ -52,9 +52,10 @@ obj-y += tmem_xen.o >>>> obj-y += radix-tree.o >>>> obj-y += rbtree.o >>>> obj-y += lzo.o >>>> +obj-y += vm_event.o >>>> +obj-y += monitor.o >>> >>> Please make the (not) sorting situation worse than it already is - the >>> original intention was for entries to be alphabetically sorted here. >> >> I'm just going to sort the list in this patch to have everything in >> alphabetic order. > > In a prereq patch then you (hopefully) mean?
Does reordering the already out-of-whack list worth its own patch? I just reordered it as part of this patch that adds to it. > >>>> +#include <public/memory.h> >>> >>> This can't be enough (nor can I see why it's needed here), or else ... >>> >>>> +/* Resumes the running of the VCPU, restarting the last instruction */ >>>> +void monitor_resume(struct domain *d); >>> >>> ... struct domain may end up being a forward reference (with scope >>> restricted to monitor_resume()). >> >> I'll revisit the headers needed for this one but it did build fine. > > Sure - presumably because the including sites included what is needed > up front. Probably. Looking at this header all it would need is xen/sched.h for the definition of struct domain. > Jan Thanks, Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
