Re: [PATCH v2 3/7] xen/vm-events: Move monitor_domctl to common-side.

[Corneliu ZUZU <czuzu@bitdefender.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1785 bytes --]

On 2/12/2016 8:05 AM, Corneliu ZUZU wrote:
> On 2/11/2016 5:44 PM, Tamas K Lengyel wrote:
>>
>>     * the #ifdefs make it possible for that code to be put in common
>>     => that makes it *clear* that those code parts are NOT
>>     architecture specific and their implementation can be safely used
>>     for all architectures.
>>
>>
>> The current practice has been to put empty static inline functions 
>> into architecture-specific headers if the part is not 
>> handled/implemented for the specific architecture. This has already 
>> been the case for monitor_domctl (there is already separate 
>> asm-arm/monitor.h and asm-x86/monitor.h) so it should be followed as 
>> more of the code moves into common.
>>
>> Tamas
>
> Point is, they *are* implemented, because that's *common* code, it 
> doesn't make sense to be moved to the arch-side
> when you know that their implementation will be *the same* from 
> arch-to-arch.
> Not *everything* needs to stay on the arch-side, just what is 
> architecture-specific - that's why e.g. arch_hvm_event_fill_regs,
> arch_hvm_event_gfn_of_ip are not in common and are static inline 
> functions as you say, because they have *different*
> implementations *depending on the architecture*.
>
> Finally, if Ian or any other ARM maintainer feels the same with moving 
> code that can be moved and has been moved to common
> back on the arch-side (effectively undoing 50% of my efforts),  I will 
> do so.
>
> Corneliu.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Actually, noted, will move single-step and software-breakpoint back on 
the arch-side as you suggest in v3.
If someone else disagrees, I suppose it will be discussed then.

Corneliu.

[-- Attachment #1.2: Type: text/html, Size: 3563 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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