[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 9/9] xenstore: when running in mini-os use printk for diagnostic messages
On 15/12/15 12:55, Juergen Gross wrote: > On 15/12/15 13:52, Ian Campbell wrote: >> On Tue, 2015-12-15 at 13:47 +0100, Juergen Gross wrote: >>> On 15/12/15 13:31, Ian Campbell wrote: >>>> On Fri, 2015-12-11 at 16:47 +0100, Juergen Gross wrote: >>>>> Xenstore messages for diagnostic purposes are lost today in case >>>>> xenstore is running under mini-os instead in a dom0 daemon. >>>> Where does vfprintf end up under mini-os? >>> TBH: I just couldn't find it. I tried to get some diagnostics when >>> I started this work and couldn't find any place where the messages >>> would occur. >>> >>>>> Use printk of mini-os in this situation. >>>> and this now ends up on the console and (for a debug h/v) in the xen >>>> dmesg, >>>> is that right? >>> The console of the xenstore domain seems to be a little bit special, as >>> there is no component up to now writing the information needed to >>> connect xenconsoled to the xenstore domain. This could be the reason I >>> wasn't able to see any message printed via vfprintf. :-( >> That sounds probable. >> >>> So in the end it will be part of xen dmesg. >> Only for a debug=y Xen, not for a release build IIRC, unless you added some >> other privilege along with your new flag which I missed. > No, this is correct. > >>> And this is where it should >>> be, as such messages will be needed in case of xenstore domain not >>> working properly. And I think it's console can be accessed by any means >>> only in case of a working xenstore. :-) >> An alternative would be init-xenstore-domain to daemonize and take on >> respoibility for consuming the console ring and throwing it into a file? > Interesting idea. I'll try this. If the stubdomain could handle buffering of its ring for a while, xenconsoled could just be used. Alternatively, have xenconsoled able to cope without xenstored while the xenstored stubdomain bootstraps itself. IMO, it would be better to have just a single consoled, rather than having a stub running alongside. A stub would necessarily need some negotiation with the main xenconsoled so they don't both map the console ring and play the part of consumer. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |