Re: [PATCH 12/12] x86: Use struct fields instead of bitmasks

[Jeremy Fitzhardinge]

Joe Damato wrote:
> Use fields in structs instead of bitmasks for getting/setting descriptor data.
>
> Signed-off-by: Joe Damato <ice799@xxxxxxxxx>
> ---
>  drivers/lguest/interrupts_and_traps.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/lguest/interrupts_and_traps.c b/drivers/lguest/interrupts_and_traps.c
> index bfb24d9..0d9c065 100644
> --- a/drivers/lguest/interrupts_and_traps.c
> +++ b/drivers/lguest/interrupts_and_traps.c
> @@ -178,7 +178,7 @@ void maybe_do_interrupt(struct lg_cpu *cpu)
>  	 * over them. */
>  	idt = &cpu->arch.idt[FIRST_EXTERNAL_VECTOR+irq];
>  	/* If they don't have a handler (yet?), we just ignore it */
> -	if (idt_present(idt->a, idt->b)) {
> +	if (idt->p) {
>   

No, using an idt_present() accessor is better, but just pass it an idt.

>  		/* OK, mark it no longer pending and deliver it. */
>  		clear_bit(irq, cpu->irqs_pending);
>  		/* set_guest_interrupt() takes the interrupt descriptor and a
> @@ -254,7 +254,7 @@ int deliver_trap(struct lg_cpu *cpu, unsigned int num)
>  
>  	/* Early on the Guest hasn't set the IDT entries (or maybe it put a
>  	 * bogus one in): if we fail here, the Guest will be killed. */
> -	if (!idt_present(cpu->arch.idt[num].a, cpu->arch.idt[num].b))
> +	if (!cpu->arch.idt[num].p)
>  		return 0;
>  	set_guest_interrupt(cpu, desc_lo(cpu->arch.idt[num]),
>  			    desc_hi(cpu->arch.idt[num]), has_err(num));
> @@ -461,7 +461,7 @@ void copy_traps(const struct lg_cpu *cpu, gate_desc *idt,
>  		 * If it can't go direct, we still need to copy the priv. level:
>  		 * they might want to give userspace access to a software
>  		 * interrupt. */
> -		if (idt_type(gidt->a, gidt->b) == 0xF)
> +		if (gidt->type == 0xF)
>   

We should have symbolic names for the IDT types.

   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/