[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 08/12] tmem: Handle 'struct tmem_info' as a seperate field in the
>>> On 28.09.16 at 11:42, <konrad.wilk@xxxxxxxxxx> wrote: > Note: We still have to do this awkward 'guest_handle_cast' > otherwise it will not compile on ARM - which defines _two_ > of these macros (__guest_handle_64_xen_sysctl_tmem_client_t > and __guest_handle_xen_sysctl_tmem_client_t). And if cast is > not used then a compile error comes up as we use the wrong one. This seems suspicious, but it's hard to judge without knowing what exactly the errors were. > --- a/xen/common/tmem_control.c > +++ b/xen/common/tmem_control.c > @@ -258,7 +258,7 @@ static int tmemc_list(domid_t cli_id, tmem_cli_va_param_t > buf, uint32_t len, > return 0; > } > > -static int __tmemc_set_var(struct client *client, uint32_t subop, > +static int __tmemc_set_var(struct client *client, > XEN_GUEST_HANDLE_PARAM(xen_sysctl_tmem_client_t) > buf) > { > domid_t cli_id = client->cli_id; > @@ -267,11 +267,6 @@ static int __tmemc_set_var(struct client *client, > uint32_t subop, > > ASSERT(client); > > - if ( subop != XEN_SYSCTL_TMEM_OP_SET_CLIENT_INFO ) > - { > - tmem_client_warn("tmem: unknown subop %d for tmemc_set_var\n", > subop); > - return -1; > - } > if ( copy_from_guest(&info, buf, 1) ) > return -EFAULT; The adjustments above look pretty unrelated to the purpose of the patch, but well - you're the maintainer of this code. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |