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

Re: [Xen-devel] [PATCH 2/2] x86/MTRR: optionally print boot time state



>>> On 17.03.14 at 16:29, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi Jan,
> 
> On 03/10/2014 11:08 AM, Jan Beulich wrote:
>> +static bool_t __initdata mtrr_show;
>> +boolean_param("mtrr.show", mtrr_show);
>> +
>> +static const char *__init mtrr_attrib_to_str(mtrr_type x)
>> +{
>> +    static const char __initconst strings[MTRR_NUM_TYPES][16] =
>> +    {
>> +            [0 ... MTRR_NUM_TYPES - 1] = "?",
>> +            [MTRR_TYPE_UNCACHABLE]     = "uncachable",
>> +            [MTRR_TYPE_WRCOMB]         = "write-combining",
>> +            [MTRR_TYPE_WRTHROUGH]      = "write-through",
>> +            [MTRR_TYPE_WRPROT]         = "write-protect",
>> +            [MTRR_TYPE_WRBACK]         = "write-back",
>> +    };
> 
> This patch is breaking compilation with clang 3.0:
> 
> generic.c:95:32: error: initializer overrides prior initialization of this 
> subobject [-Werror,-Winitializer-overrides]
>                 [MTRR_TYPE_UNCACHABLE]     = "uncachable",
>                                              ^~~~~~~~~~~~
> generic.c:94:32: note: previous initialization is here
>                 [0 ... MTRR_NUM_TYPES - 1] = "?",
>                                              ^~~
> 
> Do you mind if I send a patch to replace by something like:
>       [2] = "?"
>         [3] = "?"

Actually I do - I specifically wanted to get rid of these numeric
references (see the various other cleanup to the MTRR related
code that I sent/applied recently), and also not have pointless
definitions in place for reserved (undefined) values.

The issue looks like a compiler bug (gcc extension incompatibility)
to me, and I'm not certain we want to re-introduce ugliness just
eliminated to work around such. Do they not have any other
mechanism available by which one can use a "default" initializer
for everything not getting a specific one? If not, the next best
alternative to me would seem to be to leave these slots
completely empty, and put in place the "?" when finding a slot
to be empty.

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®.