Re: [Xen-devel] [PATCH 21/21] xen: more substitutions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.12 at 13:14, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote:
>> >>> On 05.10.12 at 12:38, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, 
> unsigned long e, void *p)
>> >      if ( s > ctxt->s )
>> >      {
>> >          e820entry_t ent;
>> > +        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t;
>> 
>> I'm not really in favor fo the _t suffix chosen here and below, as
>> that's generally used for typedef-s. Could this be replaced with
>> e.g. _p, _h, or _hp?
> 
> The use is 
>         buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t);
>         buffer = guest_handle_from_param(buffer_t, e820entry_t);
> which seems a bit strange to me -- we launder through buffer_t solely to
> use guest_handle_from_param. Is there no macro which does that in one
> step?
> 
> That would avoid the whole problem of the suffix choice.
> 
> Also buffer is then passed to __copy_to_guest_offset, and I'm not sure
> why that can't be passed ctxt->map.buffer directly rather than
> laundering it through those two macros...

Passing directly is not possible, as the type referred to be the
handle is relevant for the macro's operation (and it's "void" in
struct xen_memory_map).

Jan


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