On 4/23/25 08:58, Pierrick Bouvier wrote:
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.
It's obvious why it's done though -- expanding accel_enabled() to 0 lets the compiler do
more dead code elimination at compile-time.
r~
