Re: [Xen-devel] [RFC PATCH V2 5/8] xen: implement 3-level event channel routines

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.01.13 at 15:58, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -57,6 +57,16 @@ EXPORT_SYMBOL_GPL(evtchn_level);
>  unsigned int nr_event_channels;
>  EXPORT_SYMBOL_GPL(nr_event_channels);
>  
> +/* 2nd level selector for 3-level event channel */
> +DEFINE_PER_CPU(unsigned long [sizeof(unsigned long) * 8], evtchn_sel_l2);
> +/* shared bitmaps for 3-level event channel */
> +#define __NR_ELEMS (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)
> +unsigned long evtchn_pending[__NR_ELEMS] __page_aligned_bss;
> +unsigned long evtchn_mask   [__NR_ELEMS] __page_aligned_bss;

static across the board, even more so with the names not being
tagged (which I'm specifically _not_ asking you to do).

For the former, the array dimension surely can be expressed
better (namely in terms of constants from the interface
headers)?

For the latter - wouldn't it be better to dynamically allocate those
(not wasting the memory when running with 2 levels only, which
I hope is going to remain the default for DomU-s)? Dynamic
allocations would, judging by the rest of the patch, also allow to
have more shared code between 2 and 3 levels (as you could
point into the shared info structure in the 2 level case).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel