|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 10/11] hvm/ioreq: Negotiate extended destination ID support per ioreq server
On Thu, Sep 03, 2026 at 04:14:08PM +0200, Julian Vetter wrote: > diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h > index 698d719119..72994d1313 100644 > --- a/tools/include/xendevicemodel.h > +++ b/tools/include/xendevicemodel.h > @@ -44,12 +44,13 @@ int xendevicemodel_close(xendevicemodel_handle *dmod); > * @parm domid the domain id to be serviced > * @parm handle_bufioreq how should the IOREQ Server handle buffered > * requests (HVM_IOREQSRV_BUFIOREQ_*)? > + * @parm flags bitmask of XEN_DMOP_IOREQ_SERVER_* capability flags (0 if > none). > * @parm id pointer to an ioservid_t to receive the IOREQ Server id. > * @return 0 on success, -1 on failure. > */ > int xendevicemodel_create_ioreq_server( > xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq, > - ioservid_t *id); > + uint8_t flags, ioservid_t *id); You can't do that. libxendevicemodel is supposed to have a stable ABI so we can't change the prototype of existing functions. I think this will need a new function, with suffix "_v2", or any other different name. Then, why limit "flags" to 8bits ? Just change that to 64bits at no cost (maybe a little to check that all flags exist) and we won't need to look back, hopefully. Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |