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

["Bamvor Jian Zhang" <bjzhang@xxxxxxxx>]

Hi, Ian

 >>>Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> 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). 
thanks. I am working on it. i will send the patch v2 soon. 

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

Bamvor


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