Re: [Xen-devel] [PATCH v4] x86: wrap kexec feature with CONFIG_KEXEC

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.15 at 23:32, <jonathan.creekmore@xxxxxxxxx> wrote:
> @@ -71,6 +72,10 @@ endif
>  ifneq ($(max_phys_irqs),)
>  CFLAGS-y                += -DMAX_PHYS_IRQS=$(max_phys_irqs)
>  endif
> +ifeq ($(HAS_KEXEC)$(kexec),yy)
> +CONFIG_KEXEC := y

Apart from this line not matching blank padding wide with the ones
surrounding it I also dislike the conditional. We try to use the list
mechanism wherever possible. In this case I would hence prefer
something like

CONFIG_KEXEC-$(HAS_KEXEC) := $(kexec)
CONFIG_KEXEC := $(CONFIG_KEXEC-y)

> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -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)
> +{
> +
> +}

All the blank lines inside the functions should be removed. I'd even
consider making all of these single line items.

Neither of the changes look to be a problem to get done upon
commit, so as long as you agree I wouldn't see a need for you
to send a v5 (but of course it would be appreciated as it would
make eventual committing [once the tree re-opens] simpler).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel