[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.