Re: [PATCH 1/7] minor (formatting) fixes

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 17/06/16 09:36, Razvan Cojocaru wrote:
> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>> On 6/16/2016 7:02 PM, Tamas K Lengyel wrote:
>>>> diff --git a/xen/include/asm-arm/vm_event.h
>>>> b/xen/include/asm-arm/vm_event.h
>>>> index 014d9ba..05c3027 100644
>>>> --- a/xen/include/asm-arm/vm_event.h
>>>> +++ b/xen/include/asm-arm/vm_event.h
>>>> @@ -23,21 +23,18 @@
>>>>   #include <xen/vm_event.h>
>>>>   #include <public/domctl.h>
>>>>
>>>> -static inline
>>>> -int vm_event_init_domain(struct domain *d)
>>>> +static inline int vm_event_init_domain(struct domain *d)
>>>>   {
>>>>       /* Nothing to do. */
>>>>       return 0;
>>>>   }
>>>>
>>>> -static inline
>>>> -void vm_event_cleanup_domain(struct domain *d)
>>>> +static inline void vm_event_cleanup_domain(struct domain *d)
>>>>   {
>>>>       memset(&d->monitor, 0, sizeof(d->monitor));
>>>>   }
>>>>
>>>> -static inline
>>>> -void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>>>> +static inline void vm_event_toggle_singlestep(struct domain *d,
>>>> struct vcpu *v)
>>>>   {
>>>>       /* Not supported on ARM. */
>>>>   }
>>>> @@ -59,6 +56,9 @@ static inline void
>>>> vm_event_fill_regs(vm_event_request_t *req)
>>>>       /* Not supported on ARM. */
>>>>   }
>>>>
>>>> +/*
>>>> + * Monitor vm-events.
>>>> + */
>>> I already have an acked patch that relocates monitor-related functions
>>> from here and the x86 header to the monitor subsystem
>>> (https://patchwork.kernel.org/patch/9139999/). Generally, I'm trying
>>> to keep monitor-related stuff in the appropriately named files, so if
>>> you encounter things like this in the future the best course of action
>>> is to relocate them. vm_event should be use-case neutral by not having
>>> specific things for the monitor subsystem and just be the i/o system
>>> used for passing messages.
>>>
>>>>   static inline uint32_t vm_event_monitor_get_capabilities(struct
>>>> domain *d)
>>>>   {
>>>>       uint32_t capabilities = 0;
>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>> Since you already have a patch for that I guess it's ok to remove those
>> comments and leave the rest as it is and merge later when one of these
>> patches makes it to staging?
> I think there's a delay caused by the 4.7 release. I also have an acked
> patch waiting to go in that might cause you to have to rebase (part of)
> the series: https://patchwork.kernel.org/patch/9033771/

Staging is now open for Xen 4.8 submissions.

Would it be possible for previous submissions to be resent, or a summary
email pointing at the intended versions of the patches?  I will see
about getting stuff in.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel