Re: [Xen-devel] [patch] make evtchn_upcall_pending arch-specific type

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 1 Apr 2006, at 04:55, Jimi Xenidis wrote:

>         unsigned long evtchn_upcall_bits;
> Then:
>         #define EVTCHN_UPCALL_PENDING 0
>         #define EVTCHN_UPCALL_MASK 8
>
> use the macros to define the bit arg of the bitop_*().
> I chose these values because they would be completely compatible with 
> any assembler that exist for the itty bitty byte arches. :)  As for 
> PPC the values don't matter to us, at this early stage.
We'd have to group more than just the mask and pending flags into that 
long on x86 as otherwise we change the size of a public structure.
> > That's another one where the fields to be atomically updated are at 
> > least 8-byte aligned, and where using longer types will bloat a 
> > structure that we'd prefer to pack nicely.
> The I'd rather bloat (for PPC only) then come up with some nasty 
> read/calculate-the-actual-bit-and-modify/write.
Okay, I don't think it's so bad really, except you may want to round 
the structure size up to the next power of two (potentially) and that 
may halve MAX_VIRT_CPUS for you until we support allocating extra pages 
for higher order vCPU infos.
> > If this is the best way for ppc then I think atomic_bit_t would be a 
> > nicer typedef.
> I think a context specific typedef would be better, in most cases.
Well, I'm not too fussed. I expect atomic_bit_t would only get used in 
this one place ever anyway.
> Also,
>   - I'd like to see more use of DECLARE_BITMAP() for stuff like 
> pirq_mask
>   - more use of BITS_PER_LONG instead of (sizeof(long)*8) that occurs 
> in many places like evtchn_pending[]
Yes, for sure.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel