All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jonathan Creekmore <jonathan.creekmore@gmail.com>,
	xen-devel@lists.xenproject.org
Cc: keir@xen.org, david.vrabel@citrix.com, jbeulich@suse.com
Subject: Re: [PATCH v3] x86: wrap kexec feature with CONFIG_KEXEC
Date: Mon, 31 Aug 2015 19:47:42 +0100	[thread overview]
Message-ID: <55E4A14E.2000105@citrix.com> (raw)
In-Reply-To: <1441045917-2167-1-git-send-email-jonathan.creekmore@gmail.com>

On 31/08/15 19:31, Jonathan Creekmore wrote:
> Add the appropriate #if checks around the kexec code in the x86 codebase
> so that the feature can actually be turned off by the flag instead of
> always required to be enabled on x86.
>
> Signed-off-by: Jonathan Creekmore <jonathan.creekmore@gmail.com>

This is still not quite correct with makefile level constructs.  (Also
you have broken the ARM build).  Allow me to explain.

HAS_$foo is used to indicate whether there is support for $foo in a
particular arch.  This is statement of support, not an option. 
Therefore, xen/arch/x86/Rules.mk should remain unchanged.

The top xen/rules.mk 'kexec' option is ok, but you need a further clause
after including the per-arch rules.  Something like

ifeq($(HAS_KEXEC)$(kexec),yy)
CONFIG_KEXEC := y
endif

Which will set a Makefile level CONFIG_KEXEC which indicates that the
arch has support, and the developer wishes to enable it.

For the rest of the makefile changes, you should use things like
obj-$(CONFIG_KEXEC) and CLFAGS-$(CONFIG_KEXEC) as opposed to
$(HAS_KEXEC) and $(kexec)

With that fixed, I think this patch is ready, with one further tweak...

> @@ -79,6 +79,27 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>  #else /* !CONFIG_KEXEC */
>  
>  #define crashinfo_maxaddr_bits 0
> +#define kexecing 0
> +
> +static inline void kexec_early_calculations(void)
> +{
> +
> +}
> +
> +static inline void kexec_crash(void)
> +{
> +
> +}
> +
> +static inline void kexec_crash_save_cpu(void)
> +{
> +
> +}
> +
> +static inline void set_kexec_crash_area_size(u64 system_ram)
> +{
> +    (void)system_ram;

You shouldn't need this statement, as the callee's parameter should be
evaluated by virtue of this being a static inline.

If it is to stop the compiler complaining about an unused parameter,
please use the __unused attribute instead.

~Andrew

      reply	other threads:[~2015-08-31 19:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 18:31 [PATCH v3] x86: wrap kexec feature with CONFIG_KEXEC Jonathan Creekmore
2015-08-31 18:47 ` Andrew Cooper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E4A14E.2000105@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jonathan.creekmore@gmail.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.