Re: [Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-05-15 at 06:06 +0100, Bamvor Jian Zhang wrote:
> >> +int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path)
> >> +{
> >
> >We already have various functions to refer to and open consoles, which
> >have much of this functionality in them already.  That shouldn't be
> >duplicated.
> >
> >Also we need to make a policy decision about whether the fact that the
> >console looks like a tty is a part of the API.

> sorry i only found one api about open console is libxl_console_exec.
> libxl_console_exec call xenconsole command directly which is not
> compatible with libvirt open console api. libvirt open console want a
> console device path and handle the console by libvirt itself. libvirt
> xen(not xenlight) driver read console path from xenstore directly
> which is prohibited by libvirt xenlight drvier. 
> So, because these reasons, i guess add this simple api to return
> console path to libvirt is a good choice. it is useful for libvirt and
> do not break libxl api. 

We actually discussed the existing interface in the context of the libxl
stable API (sub-thread starting at
<20357.44324.27939.514126@xxxxxxxxxxxxxxxxxxxxxxxx> which has a lot of
sub-threads. Another interesting bit starts at
<20358.47143.994639.76453@xxxxxxxxxxxxxxxxxxxxxxxx>)

In that thread IanJ said:
> ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> libxl_console_type type);
> ]   /* libxl_primary_console_exec finds the domid and console number
> ]    * corresponding to the primary console of the given vm, then calls
> ]    * libxl_console_exec with the right arguments (domid might be different
> ]    * if the guest is using stubdoms).
> ]    * This function can be called after creating the device model, in
> ]    * case of HVM guests, and before libxl_run_bootloader in case of PV
> ]    * guests using pygrub. */
> ]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
> 
> These functions should not exec things for you; they should tell you
> the parameters.  Any execing helpers should be in libxlu.

and later on he said, in response to some of my musings:
> But what if your vnc viewer doesn't have the command line options
> these functions expect ?  libxl_vncviewer_* should give you an idl
> struct containing the ip address (or perhaps the domain name), port
> number, and password.

I think the same can be said of libxl_console_*.

In the end I decided:
> this seems like 4.3 material at this stage.
> 
> I'd expect that the functions which behaved this way would not be
> called ..._exec (perhaps ..._get_params or so) so implementing the
> proper interface in 4.3 won't cause a compat issue.

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).

I don't see any need for it to be a requirement to switch xl over to
this new interface at this stage, but we could mark the exec functions
as already deprecated in 4.2 and plan to do so (with associated libxlu
helpers) in 4.3.

This still leaves us having to decide if we want to expose the fact that
the console is a tty. Perhaps a compromise would be to include a
libxl_console_type enum and KeyedUnion of params, currently the only
possible value for the enum would be "PTY" (or "TTY")? (or maybe we can
leave that until the second one comes along...)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel