[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] xen: introduce XENMEM_get_dma_buf and XENMEM_put_dma_buf
>>> On 08.08.13 at 16:44, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> >>> wrote: > On Thu, 8 Aug 2013, Jan Beulich wrote: >> >>> On 08.08.13 at 16:12, Stefano Stabellini >> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote: >> > On Thu, 8 Aug 2013, Jan Beulich wrote: >> >> >>> On 05.08.13 at 18:40, Stefano Stabellini >> >> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote: >> >> > @@ -630,8 +690,15 @@ long do_memory_op(unsigned long cmd, >> > XEN_GUEST_HANDLE_PARAM(void) arg) >> >> > >> >> > break; >> >> > >> >> > + case XENMEM_get_dma_buf: >> >> > + /* xen_get_dma_buf_t is identical to xen_memory_exchange_t, so >> >> > + * just cast it and reuse memory_exchange */ >> >> >> >> Then why do you define a new type for it in the first place? >> > >> > Because the original hypercall doesn't copy back the mfn if the guest >> > it's an autotranslate guest. >> > And because it doesn't pin the p2m mappings. >> >> Hmm, I'm confused: Here you reason why you want a new type >> (note that I said "type", not "sub-hypercall"), ... >> >> >> And anyway, the naming of the new sub-op isn't really >> >> representing what the operation is capable of. >> >> XENMEM_exchange_and_pin would seem to come much closer. >> > >> > I like this suggestion. I could also keep xen_memory_exchange as >> > argument for XENMEM_exchange_and_pin, as Ian suggested. >> >> ... yet here you agree that xen_memory_exchange could be >> re-used. > > I meant only to keep the same parameter struct xen_memory_exchange. And that's what I asked for. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |