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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-10-05 at 12:33 +0100, Jan Beulich wrote:
> >>> 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).

That's the bit I missed.

Although the question is then why not type the buffer correctly...

Ian/


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