[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Plumb through xen-platform device logging
On 07/11/13 08:07, Paul Durrant wrote: -----Original Message----- From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx] Sent: 11 July 2013 12:44 To: Paul Durrant Cc: xen-devel@xxxxxxxxxxxxx Subject: Re: [Xen-devel] [PATCH] Plumb through xen-platform device logging On Thu, 2013-07-11 at 08:23 +0000, Paul Durrant wrote:diff --git a/tools/Makefile b/tools/Makefile index e44a3e9..2d791a4 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -202,7 +202,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find --disable-kvm \ --disable-docs \ --python=$(PYTHON) \ - $(IOEMU_CONFIGURE_CROSS); \ + $(IOEMU_CONFIGURE_CROSS) \ + --enable-trace-backend=stderr; \ I have done this in a more flexable way: --- a/tools/Makefile +++ b/tools/Makefile @@ -187,8 +185,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find source=.; \ fi; \ cd qemu-xen-dir; \ - $$source/configure --enable-xen --target-list=i386-softmmu \ - --prefix=$(PREFIX) \+ $$source/configure --enable-xen $(QEMU_UPSTREAM_EXTRA_CONFIG) --target-list=i386-softmmu \ --source-path=$$source \ --extra-cflags="-I$(XEN_ROOT)/tools/include \ -I$(XEN_ROOT)/tools/libxc \I.E by adding QEMU_UPSTREAM_EXTRA_CONFIG which I add to .config when I want to turn on tracing. It is static and adds a lot of code. So you want a way to not configure it also. However what trace output happens is changeable while running.Is this the only way to do this? It is likely that many distros will use their standard qemu packages which may or may not have this option enabled.That's true.I'm not sure if this is a static always on option or if this is simply making a trace backend available for use.It's a static selection as far as I can tell. The tracing backend is not selectable at runtime :-( Using --enable-trace-backend=stderr, the output ends up in /var/log/xen/qemu-dm-P-1-0.logLooking at http://wiki.qemu.org/Features/Tracing is the tracing interface really the right way to be logging this particular class of information? I'd have thought a simple logfile support in the platform device would be a much more natural fit.That makes sense to me, but whoever coded up the platform device obviously believed tracing to be the correct way to log. I don't know the history of that decision. It doesn't change the fact though that, currently, xen builds of QEMU don't configure any form of tracing backend at all which doesn't seem particularly helpful, and I did introduce platform logging as an example of an event to log so I think the patch is useful as far as it goes, but maybe another patch to the platform device in QEMU would also be considered a good idea. Paul$(MAKE) all diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 2924298..35f71cc 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -370,6 +370,13 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, "-xen-domid", libxl__sprintf(gc, "%d", guest_domid), NULL); + flexarray_vappend(dm_args, + "-trace", + libxl__sprintf(gc, + "events=%s/qemu-trace-events", + libxl__xen_config_dir_path()), + NULL);Doesn't this end up logging to /etc/xen? Not what we want I think. or maybe this is just the config file, which, apart from my comments about the suitability of the interface above, makes me wonder where the logs do go? Ideally they would go to /var/log/xen/qemu-blah-name.log not to xl stdout. I.E. where all stderr from qemu does. -Don Slutz _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |