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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.12 at 13:40, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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...

Because the type itself isn't Xen-defined and hence also not
exposed in Xen's public interface (which in particular allows
guests to use their own type without any need of casting).

Jan

Jan


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