Re: [RFC PATCH V3 11/12] xen/vm_event: Decouple vm_event and mem_access.

[Tamas K Lengyel <tamas.lengyel@zentific.com>]

On Fri, Feb 6, 2015 at 3:20 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 06.02.15 at 14:10, <tamas.lengyel@zentific.com> wrote:
>> On Wed, Feb 4, 2015 at 10:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 29.01.15 at 22:46, <tamas.lengyel@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