From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corneliu ZUZU Subject: Re: [PATCH v2 3/7] xen/vm-events: Move monitor_domctl to common-side. Date: Fri, 12 Feb 2016 08:05:55 +0200 Message-ID: <56BD7643.1030206@bitdefender.com> References: <1455119259-2161-1-git-send-email-czuzu@bitdefender.com> <1455119548-2401-1-git-send-email-czuzu@bitdefender.com> <56BB74B8.1020207@bitdefender.com> <56BC366F.5060802@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1284316515064409952==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel Cc: Kevin Tian , Keir Fraser , Ian Campbell , Razvan Cojocaru , Jun Nakajima , Andrew Cooper , Xen-devel , Stefano Stabellini , Jan Beulich List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============1284316515064409952== Content-Type: multipart/alternative; boundary="------------050208020504010307080302" This is a multi-part message in MIME format. --------------050208020504010307080302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------050208020504010307080302 Content-Type: text/html; charset=utf-8 Content-Length: 2558 Content-Transfer-Encoding: quoted-printable
On 2/11/2016 5:44 PM, Tamas K Lengyel wrote:
* the #ifdefs make it possible for that code to be put in common =3D> 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),=C2=A0 I will do so.

Corneliu.
--------------050208020504010307080302-- --===============1284316515064409952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1284316515064409952==--