[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff
Bamvor Jian Zhang writes ("Re: [Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff"): > Hi, Ian > > I think I'd be happy to make a freeze exception for a patch which > > implemented the returning of an IDL struct representing the console > > device for the benefit of libvirt, so long as it is pretty much self > > contained (which I think it will be). > > thanks. I am working on it. i will send the patch v2 soon. Sorry to throw a spanner in the works, but I think actually that this isn't really the right approach. Having the considered the question I think we should indeed expose the fact that there is (or can be) a tty as part of the libxl API. And I don't really want to introduce a new complex IDL struct with only one user. So your old interface, along these lines, is good: int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path) However, it should probably be in teh same pattern as libxl_console_exec and libxl_primary_console_exec. So: int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type, char **path); int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid, char **path); These should probably reuse the same innards as the _exec functions. Are you planning to do anything about libxl_vncviewer_exec ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |