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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
