[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 01/34] compat/x86: Remove unncessary #define.



>>> On 17.03.16 at 01:44, <konrad@xxxxxxxxxx> wrote:
> On Wed, Mar 16, 2016 at 05:08:30AM -0600, Jan Beulich wrote:
>> >>> On 15.03.16 at 18:56, <konrad.wilk@xxxxxxxxxx> wrote:
>> > It is not used.
>> 
>> Consistently please - either keep them all (just to cover the case
>> that they might get used) or remove them all: xen_compile_info,
>> xen_changeset_info, etc are all unused too. Otoh
>> xennmi_callback is used, but xennmi_callback_t isn't. Which to me
>> suggests that we should leave this alone.
> 
> Oddly enough taking an cleaver to it was OK.
> 
> From 7e3ed6faed6e083f27ad6be947ac528c3eaba9a1 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Date: Wed, 2 Mar 2016 12:50:32 -0500
> Subject: [PATCH v4 02/35] compat/x86: Remove unncessary #defines.
> 
> They are not used.

This now goes too far.

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Hence this can't stay.

> ---
> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Keir Fraser <keir@xxxxxxx>
> Cc: Tim Deegan <tim@xxxxxxx>
> 
> v2: Remove a lot more of them.

(Side note: Not only this time round I notice versioning mixup in
your patches: The subject says v4 here, yet the update to it
above says v2. In the previous round of the xSplice series - v3 -
I seem to recall there were patches showing a "history" up to
something like v9. I think in cases of such heavy mixing it should
be the patch with the oldest history that determines the version
of the entire series.)

> --- a/xen/common/compat/kernel.c
> +++ b/xen/common/compat/kernel.c
> @@ -18,30 +18,22 @@ asm(".file \"" __FILE__ "\"");
>  
>  extern xen_commandline_t saved_cmdline;
>  
> -#define xen_extraversion compat_extraversion
>  #define xen_extraversion_t compat_extraversion_t
>  
> -#define xen_compile_info compat_compile_info
>  #define xen_compile_info_t compat_compile_info_t
>  
>  CHECK_TYPE(capabilities_info);
>  
> -#define xen_platform_parameters compat_platform_parameters
>  #define xen_platform_parameters_t compat_platform_parameters_t
>  #undef HYPERVISOR_VIRT_START
>  #define HYPERVISOR_VIRT_START HYPERVISOR_COMPAT_VIRT_START(current->domain)
>  
> -#define xen_changeset_info compat_changeset_info
>  #define xen_changeset_info_t compat_changeset_info_t
>  
> -#define xen_feature_info compat_feature_info
>  #define xen_feature_info_t compat_feature_info_t
>  
>  CHECK_TYPE(domain_handle);
>  
> -#define xennmi_callback compat_nmi_callback
> -#define xennmi_callback_t compat_nmi_callback_t

The former definitely is being used; not getting a compilation
error here is not a sign of things being right. That's another
reason why - as I had suggested already - we'd probably
better leave things as they are: Introduction of uses of the
now removed identifiers might otherwise break compat code
without anyone noticing right away.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.