[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/7] xen/public: arch-arm: Restrict the visibility of struct vcpu_guest_core_regs



On Fri, 26 Jul 2019, Volodymyr Babchuk wrote:
> > On 26/07/2019 13:14, Volodymyr Babchuk wrote:
> >>
> >> Hi Julien,
> >
> > Hi Volodymyr,
> >
> >> Julien Grall writes:
> >>
> >>> Currently, the structure vcpu_guest_core_regs is part of the public API.
> >>> This implies that any change in the structure should be backward
> >>> compatible.
> >>>
> >>> However, the structure is only needed by the tools and Xen. It is also
> >>> not expected to be ever used outside of that context. So we could save us
> >>> some headache by only declaring the structure for Xen and tools.
> >>>
> >>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >>> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
> >>> ---
> >>>      This is a follow-up of the discussion [1].
> >>>
> >>>      [1] <3c245c5b-51c6-1d0e-ad6c-42414573166f@xxxxxxx>
> >>>
> >>>      Changes in v3:
> >>>          - Avoid introduce a new #ifdef in the header by moving the
> >>>          definitions later on.
> >>> ---
> >>>   xen/include/public/arch-arm.h | 24 ++++++++++++------------
> >>>   1 file changed, 12 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >>> index 3e8cdc151d..7ce139a0f5 100644
> >>> --- a/xen/include/public/arch-arm.h
> >>> +++ b/xen/include/public/arch-arm.h
> >>> @@ -197,6 +197,18 @@
> >>>       } while ( 0 )
> >>>   #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, 
> >>> val)
> >>>   +typedef uint64_t xen_pfn_t;
> >>> +#define PRI_xen_pfn PRIx64
> >>> +#define PRIu_xen_pfn PRIu64
> >>> +
> >>> +/* Maximum number of virtual CPUs in legacy multi-processor guests. */
> >>> +/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
> >> Just a suggestion: you already touching this part. Maybe you'll fix this
> >> comment as well?
> >
> > I am not sure what's wrong with the current comment. Can you expand
> > your thoughts please?
> Sure. It does not conform to CODING_STYLE:
> 
>    Comments containing a single sentence may end with a full
>    stop; comments containing several sentences must have a full stop
>    after each sentence.
> 
> The second comment misses full stop at the end. Also, maybe we should
> consider this as s multi-line comment:
> 
>    Multi-line comment blocks should start and end with comment markers on
>    separate lines and each line should begin with a leading '*'.

I'll improve on commit

Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.