On Thu, Jun 23, 2016 at 01:48:35PM +0100, Andrew Cooper wrote:
> On 23/06/16 13:44, Wei Liu wrote:
> > On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> >>>>> On 23.06.16 at 12:50, <wei.l...@citrix.com> wrote:
> >>> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >>>>>>> On 20.06.16 at 18:30, <wei.l...@citrix.com> wrote:
> >>>>> @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >>>>>  
> >>>>>  #ifndef opt_hvm_fep
> >>>>>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> >>>>> -bool_t opt_hvm_fep;
> >>>>> +bool_t __read_mostly opt_hvm_fep;
> >>>>>  boolean_param("hvm_fep", opt_hvm_fep);
> >>>>>  #endif
> >>>>> +static const char __initconst *warning_hvm_fep =
> >>>>> +    "**********************************************\n"
> >>>>> +    "******* WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
> >>>>> +    "******* This option is *ONLY* intended to aid testing of Xen.\n"
> >>>>> +    "******* It has implications on the security of the system.\n"
> >>>>> +    "******* Please *DO NOT* use this in production.\n"
> >>>>> +    "**********************************************\n";
> >>>>> +
> >>>>>  
> >>>> Along with the same comment as on patch 2, here even more than
> >>>> there I wonder whether this string wouldn't better be a static local
> >>>> in hvm_enable() (or even the scope therein where warning_add()
> >>>> gets invoked).
> >>> I would rather the text stays next to where the option is defined so
> >>> it is obvious to anyone who touches this area of code.
> >> Makes sense. But then - shouldn't it move inside the #ifndef?
> >>
> > That would then require the warning_add() call to be wrapped in ifdef,
> > too. That looks a bit cumbersome to me.
> 
> You can do something like:
> 
> #ifndef $FOO
> #define warning_text NULL
> #else
> const static __initdata warning_text[] = "BAR";
> #endif
> 
> This works in the same way as the current opt_hvm_fep define.
> 

Sure, that works for me, too.

Wei.

> ~Andrew

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

Reply via email to