On 12/07/2021 21:32, Daniel P. Smith wrote:
> diff --git a/xen/include/xen/alternative-call.h
> b/xen/include/xen/alternative-call.h
> new file mode 100644
> index 0000000000..11d1c26068
> --- /dev/null
> +++ b/xen/include/xen/alternative-call.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef XEN_ALTERNATIVE_CALL
> +#define XEN_ALTERNATIVE_CALL
> +
> +/*
> + * Some subsystems in Xen may have multiple implementions, which can be
> + * resolved to a single implementation at boot time. By default, this will
> + * result in the use of function pointers.
> + *
> + * Some architectures may have mechanisms for dynamically modifying .text.
> + * Using this mechnaism, function pointers can be converted to direct calls
> + * which are typically more efficient at runtime.
> + *
> + * For architectures to support:
> + *
> + * - Implement alternative_{,v}call() in asm/alternative.h. Code generation
> + * requirements are to emit a function pointer call at build time, and
> stash
> + * enough metadata to simplify the call at boot once the implementation has
> + * been resolved.
> + * - Select ALTERNATIVE_CALL in Kconfig.
> + *
> + * To use:
> + *
> + * Consider the following simplified example.
> + *
> + * 1) struct foo_ops __alt_call_maybe_initdata ops;
> + *
> + * 2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
> + * struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };
It occurs to me after reviewing patch 2 that these want to be const
struct foo_ops __initconst ..., and there is no need for
__alt_call_maybe_initconst at all.
The only thing wanting a conditional annotation like this is the single
ops object, and it needs to be initdata (or hopefully ro_after_init in
the future).
~Andrew
