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

Re: [Xen-devel] [PATCH v3] xen/keyhandler: Rework keyhandler infrastructure



>>> On 24.09.15 at 13:47, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/09/15 12:46, Jan Beulich wrote:
>>>>> On 24.09.15 at 13:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +static struct keyhandler {
>>> +    union {
>>> +        keyhandler_fn_t *fn;
>>> +        irq_keyhandler_fn_t *irq_fn;
>>> +    };
>>> +
>>> +    const char *desc;    /* Description for help message.                 
> */
>>> +    bool_t irq_callback, /* Call in irq context? if not, tasklet context. 
> */
>>> +        diagnostic;      /* Include in 'dump all' handler.                
> */
>>> +} key_table[128] __read_mostly =
>>> +{
>>> +#define KEYHANDLER(k, f, desc, diag)            \
>>> +    [k] = { .fn = (f), desc, 0, diag }
>>> +
>>> +#define IRQ_KEYHANDLER(k, f, desc, diag)        \
>>> +    [k] = { .irq_fn = (f), desc, 1, diag }
>> I'm sorry for noticing only now, but I'm afraid these (looking as
>> odd - but correct - as the other ones did) won't build with older
>> gcc either.
> 
> Urgh yes.  I think we might have to just explicitly typecast the
> pointer, because .irq_fn is uninitialised in older GCC.  Would that be ok?

Yes, certainly better than re-adding the u name. Another
alternative would be a void * as the first union alternative,
but I suppose future gcc might become more strict about
conversions between function and data pointers...

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