On 4/23/25 02:22, Philippe Mathieu-Daudé wrote:
Hi Pierrick,
On 22/4/25 21:26, Richard Henderson wrote:
From: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20250317183417.285700-14-pierrick.bouv...@linaro.org>
---
include/system/xen-mapcache.h | 41 -----------------------------------
include/system/xen.h | 21 +++---------------
2 files changed, 3 insertions(+), 59 deletions(-)
diff --git a/include/system/xen.h b/include/system/xen.h
index 990c19a8ef..5f41915732 100644
--- a/include/system/xen.h
+++ b/include/system/xen.h
@@ -25,30 +25,15 @@
#endif /* COMPILING_PER_TARGET */
#ifdef CONFIG_XEN_IS_POSSIBLE
-
extern bool xen_allowed;
-
#define xen_enabled() (xen_allowed)
+#else /* !CONFIG_XEN_IS_POSSIBLE */
+#define xen_enabled() 0
+#endif /* CONFIG_XEN_IS_POSSIBLE */
Just to be sure, you said we should remove CONFIG_XEN_IS_POSSIBLE?
More "Ideally, it should not have been introduced", and {accel}_enabled
should be a proper function, and needed stubs should be added for other
functions.
CONFIG_{ACCEL}_IS_POSSIBLE is just "yet another way" to stub some
accelerator functions, while we could have proper stubs instead.
As long as it's not blocking our work, I don't think we should do this
cleanup.
For your case, concerning hvf, I said it would be preferable to simply
implement hvf_enabled() as normal function, instead of mimicking the
CONFIG_{ACCEL}_IS_POSSIBLE pattern, since it has not yet been introduced
for this accelerator.
It it's more simple to simply replicate this, no worries, go ahead, it
just concerns one header.
When we'll want to link the single binary for the first time, we'll have
to deal with that anyway, as it won't be possible to have two different
definition of a single function/symbol (i.e. unify stubs and
implementations). But we are not yet there, and it's better to focus our
energy on removing compilation units duplication at the moment.
