[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 1/15]: PVH xen: turn gdb_frames/gdt_ents into union
At 15:54 +0000 on 24 Jan (1359042878), Jan Beulich wrote: > >>> On 24.01.13 at 16:45, Tim Deegan <tim@xxxxxxx> wrote: > > At 15:37 +0000 on 24 Jan (1359041870), Jan Beulich wrote: > >> >>> On 24.01.13 at 15:29, Tim Deegan <tim@xxxxxxx> wrote: > >> > At 17:25 -0800 on 11 Jan (1357925122), Mukesh Rathor wrote: > >> >> diff -r bf249cd5f2c1 -r 278d7a933d88 xen/include/public/arch-x86/xen.h > >> >> --- a/xen/include/public/arch-x86/xen.h Tue Oct 30 18:12:11 2012 +0000 > >> >> +++ b/xen/include/public/arch-x86/xen.h Fri Jan 11 16:19:40 2013 -0800 > >> >> @@ -157,7 +157,16 @@ struct vcpu_guest_context { > >> >> struct cpu_user_regs user_regs; /* User-level CPU > >> >> registers > > > >> > */ > >> >> struct trap_info trap_ctxt[256]; /* Virtual IDT > >> >> > > > >> > */ > >> >> unsigned long ldt_base, ldt_ents; /* LDT (linear address, # > > ents) > >> > */ > >> >> - unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # > >> >> ents) > > > >> > */ > >> >> + union { > >> >> + struct { > >> >> + /* GDT (machine frames, # ents) */ > >> >> + unsigned long gdt_frames[16], gdt_ents; > >> >> + } pv; > >> >> + struct { > >> >> + /* PVH: GDTR addr and size */ > >> >> + unsigned long gdtaddr, gdtsz; > >> > > >> > The GDT size is always 16 bits; I'd be inclined to make the addr > >> > explicitly 64 bits too, to help out 32-bit toolstacks. > >> > > >> >> + } pvh; > >> >> + } u; > >> > > >> > Also, would you consider renaming this as: > >> > > >> > union { > >> > struct { > >> > /* GDT (machine frames, # ents) */ > >> > unsigned long frames[16], ents; > >> > } pv; > >> > struct { > >> > /* PVH: GDTR addr and size */ > >> > unsigned long addr, sz; > >> > } pvh; > >> > } gdt; > >> > > >> > ? Then the calling code looks a little nicer. > >> > >> Did you overlook that it is a public header that gets modified > >> here? > > > > No, but you already pointed that out so I didn't feel the need to. I'm > > just suggesting that if we're going to change the naming here, we can > > change it to something nicer. > > But we shouldn't change names or types here arbitrarily. It's > one thing if something truly needs fixing, but another if it's merely > cosmetic. My comment about types was about a field that is added _in this patch_! Likewise the renaming -- this patch already requires callers to s/gdt_frames/u.pv.gdt_frames/g. Making it so users have to do s/gdt_frames/gdt.pv.frames/g doesn't make that any worse. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |