On 10/6/15 4:47 AM, Andrew Cooper wrote: > On 05/10/15 23:03, Doug Goldstein wrote: >> Use the Kconfig generated HAS_PASSTHROUGH defines for the code base. >> >> Signed-off-by: Doug Goldstein <car...@cardoe.com> >> > > Moving to a Kconfig style of selecting features changes the meaning of > our HAS_ prefix. > > IMO, the HAS_ should disappear in the conversion, as the CONFIG_* itself > existing indicates that kconfig has decided that a feature is present. > > ~Andrew >
So I am treating the CONFIG_HAS_ defines similar to how the Linux kernel has CONFIG_HAVE_. These are not actually user facing options but instead they are enforced by the architecture instead of being a user facing option. For example CONFIG_HAS_KEXEC means the architecture/platform supports KEXEC but CONFIG_KEXEC would be the user configurable option to turn it on/off. This would be consistent with the current behavior in the Xen tree where HAS_KEXEC means the architecture/platform supports KEXEC while 'kexec' as an env var allows the user to build kexec on or off. If that's not desired I can combine them. -- Doug Goldstein
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
