This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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

        unsigned long evtchn_upcall_bits;
        #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.

- 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