Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for guest_handle_cast

[Tim Deegan <tim@xxxxxxx>]

At 16:39 +0100 on 14 Jun (1339691953), Jean Guyader wrote:
> On 14/06 03:40, Jean Guyader wrote:
> > On 14/06 03:27, Tim Deegan wrote:
> > > At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > > > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > > > Maybe I should put here the reason that led me to do something
> > > > > like that. Here is what I'm trying to do:
> > > > > 
> > > > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > > > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > > > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > > > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > > > 
> > > > > I need to cast to uint8_t first to get the add_offset to behave
> > > > > correctly. Maybe what I need would need a new macro that would
> > > > > do those two operations.
> > > > > 
> > > > > What would be the proper way to doing something like this?
> > > > 
> > > > You could avoid it altogether by dropping struct v4v_ring_data, and
> > > > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > > > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > > > fields.
> > > 
> > > Excuse me, I meant struct v4v_pfn_list_t.
> > > 
> > 
> > You probably mean both, because we doing the same thing with
> > v4v_ring_data_t and v4v_ring_data_ent_t.
> > 
> 
> Actually I don't want to get rid of the v4v_ring_data_t struct.
> 
> The idea being this struct is that we might want to extend it in the future
> so having a wrapper arround with a magic is important to detect which
> version of the struct is being used.

Do you have concrete ideas for how you might want to extend the header,
or is this just generic futureproofing?

Since each of these structs is only used for one command you can
allocate new command numbers if you need to add more arguments later.
That's worked well enough for other hypercalls in the past.

Cheers,

Tim.

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