[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote: > >>> On 23.06.16 at 12:50, <wei.liu2@xxxxxxxxxx> wrote: > > On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote: > >> >>> On 20.06.16 at 18:30, <wei.liu2@xxxxxxxxxx> 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. Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |