[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface
Hi Jan, On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote: >>>> On 20.01.16 at 09:31, <van.freenix@xxxxxxxxx> wrote: >> +/* >> + * Backend response >> + * >> + * cmd: command for operation on clk, same with the cmd in request. >> + * id: clk id, same with the id in request. >> + * success: indicate failure or success for the cmd. >> + * rate: clock rate. Used for get rate. >> + * >> + * cmd and id are filled by backend and passed to frontend to >> + * let frontend check whether the response is for the current >> + * request or not. >> + */ >> +struct xen_clkif_response { >> + uint32_t cmd; >> + uint32_t id; >> + uint32_t success; >> + uint64_t rate; >> +}; > >This isn't 32-/64-bit clean. Question is whether echoing cmd is really >needed. As Juergen suggested, use a request id. I'll fix this in V3. 32-/64-bit unclean, I can not get you here (: > >Also naming a field "success" is pretty odd - is this mean to be a >boolean? Better name it e.g. status, allowing for different (error) >indicators. As you suggested, how about `int status`? And in this clkif.h, define different status value, such as `#define XEN_CLK_PREPARE_OK 0, #define XEN_CLK_PREPARE_FAILURE -1`. The frontend and backend should be aware of the status value. > >And what I'm missing throughout the file is some description of how >clock events (interrupts?) are actually meant to make it into the >guest. I have a simple implementation v1 patch for linux, http://lists.xen.org/archives/html/xen-devel/2016-01/msg01860.html. You can see how it works. Thanks, Peng. > >Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |