On Thu, 23 Jun 2011, Ian Campbell wrote:
> On Mon, 2011-06-20 at 19:42 +0100, Stefano Stabellini wrote:
> > > @@ -198,6 +248,10 @@ static int con_init(struct XenDevice *xendev)
> > > else
> > > con->chr = serial_hds[con->xendev.dev];
> > >
> > > + logenv = getenv("XENCONSOLED_TRACE");
> > > + if (logenv != NULL && !strcmp(logenv, "guest")) {
> > > + log_guest = 1;
> > > + }
> > > return 0;
> > > }
> >
> > please check the length of logenv before using strcmp on it
>
> surely getenv() isn't the correct interface anyway?
>
> What guarantees that the environment running qemu will have
> the /etc/sysconfig/xencommons derived settings in it? It's not usually
> the case under xl unless the user happens to have sources the file
> (which would be strange).
>
> Also XENCONSOLED_TRACE is clearly a setting aimed at xenconsoled -- not
> qemu. In fact it is really a setting for the xencommons initscript which
> turns it into the appropriate xenconsoled command line option.
Considering that xenconsoled and qemu consoles are equivalent and
interchangeable, it is a good idea to support XENCONSOLED_TRACE is qemu
as well.
How we do that is another matter.
It is certainly more coherent from the qemu point of view if we pass
it as a command line option, like Anthony suggested.
> Perhaps we should be plumbing the console to xenconsoled (like we do for
> serial = pty), that'll get us this logging for free and be consistent to
> Xen users compared with PV guests, HVM serial=pty and similar...
xenconsoled doesn't support any output other than a pty and doesn't
support multiple PV consoles, that are going to be required at least for
linux stubdoms.
> The other option would be to properly plumb this stuff through the qemu
> command line and make use of it from the Xen toolstack as necessary.
That would be good, maybe cleaner.
