Log qemu-dm's message with date, time and pid
PATCH 1/1 Log qemu-dm's message with date, time and pid
The qemu-dm's log message doesn't have date, time, and pid. It is difficult to find out the message we want.
This patch solves the problem without changing the codes which write messages.
We developed a small program called ioemu-logger. qemu-dm creates a pipe and starts ioemu-logger. qemu-dm associates a stream with the pipe, and sets the stream to existing "logfile" variable. When qemu-dm writes a message to "logfile", ioemu-logger receive it through the pipe and outputs it with date, time and pid to the actual log file.
-----------------------
Yosuke Iwamatsu
NEC Corporation
Log qemu-dm's message with date, time and pid.
tools/Makefile +2 -0
@@ -23,6 +23,7 @@ SUBDIRS-y += libfsimage SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen SUBDIRS-$(CONFIG_IOEMU) += ioemu +SUBDIRS-$(CONFIG_IOEMU) += ioemu-logger # These don't cross-compile ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -61,4 +62,5 @@ subdir-all-ioemu subdir-install-ioemu: i subdir-clean-ioemu: $(MAKE) -C ioemu distclean + $(MAKE) -C ioemu-logger distclean
tools/ioemu-logger/Makefile new file +21 -0
@@ -0,0 +1,21 @@ +XEN_ROOT=../.. +include $(XEN_ROOT)/tools/Rules.mk +-include $(XEN_ROOT)/tools/ioemu/config-host.mak + +TARGET = ioemu-logger + +.PHONY: all +all: $(TARGET) + +.PHONY: install +install: all + $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(bindir)/$(TARGET) + +.PHONY: clean +clean: + rm -f $(TARGET) *.o + +.PHONY: distclean +distclean: clean + +$(TARGET): ioemu-logger.o
tools/ioemu-logger/ioemu-logger.c new file +43 -0
43 lines not on this page · raw message
tools/ioemu/cpu-all.h +1 -1
@@ -822,7 +822,7 @@ extern CPULogItem cpu_log_items[];extern CPULogItem cpu_log_items[];void cpu_set_log (int log_flags); -void cpu_set_log_filename (const char *filename); +void start_logger (void );int cpu_str_to_log_mask (const char *str);/* IO ports API */
tools/ioemu/target-i386-dm/exec-dm.c +39 -7
58 lines not on this page · raw message
tools/ioemu/vl.c +41 -2
78 lines not on this page · raw message
tools/ioemu/vl.h +2 -1
@@ -155,7 +155,8 @@ int set_mm_mapping(int xc_handle, uint32 unsigned int address_bits, unsigned long *extent_start);extern FILE *logfile; - +extern int log_pid; +extern int backup_stderr;#if (defined(__i386__) || defined(__x86_64__)) && !defined(QEMU_TOOL )#define MAPCACHE
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines · Yosuke Iwamatsu
We developed a small program called ioemu-logger. qemu-dm creates a pipe and starts ioemu-logger. qemu-dm associates a stream with the pipe, and sets the stream to existing "logfile" variable. When qemu-dm writes a message to "logfile", ioemu-logger receive it through the pipe and outputs it with date, time and pid to the actual log file.
Why do you need yet another executable for this rather small piece of functionality? Shouldn't it be possible to do that all in qemu-dm itself (and possibly with even less code)?
Kevin
Yosuke Iwamatsu writes ("[Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 2 lines
The qemu-dm's log message doesn't have date, time, and pid. It is difficult to find out the message we want.
I agree with Kevin Wolf's comments. But I would go further: why can this not be done by the code in xend which starts qemu-dm ? That would avoid any change to the qemu code.
Also, I think I would discourage the introduction of new features in tools/ioemu. I would much prefer submissions to be made against my new merged qemu tree, which you can currently find at
http://www.chiark.greenend.org.uk/~ijackson/qemu-xen.git
Ian.
Quoted 4 lines · Ian Jackson
Yosuke Iwamatsu writes ("[Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 2 lines
The qemu-dm's log message doesn't have date, time, and pid. It is difficult to find out the message we want.
Quoted 8 lines
I agree with Kevin Wolf's comments. But I would go further: why can this not be done by the code in xend which starts qemu-dm ? That would avoid any change to the qemu code.
Also, I think I would discourage the introduction of new features in
tools/ioemu. I would much prefer submissions to be made against my new merged qemu tree, which you can currently find at
http://www.chiark.greenend.org.uk/~ijackson/qemu-xen.git
What are your plans wrt to QEMU longer term ? Are you going to merge this GIT repo into tools/ioemu in xen-unstable.hg, or thinking its better to keep a separate tree on an ongoing basis ? Would we have synced up releases of the two, or try to apply some ABI stability to libxc and libxenstore APIs to allow separate release of QEMU vs XenD tools ? The latter could be interesting because apps like Xenner are able to use QEMU-DM in isolation from the rest of the XenD stack.
Regards,
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
What are your plans wrt to QEMU longer term ? Are you going to merge this GIT repo into
tools/ioemuin xen-unstable.hg, or thinking its better to keep a separate tree on an ongoing basis ?
No, I don't think it's practical to keep this tree in xen-unstable.hg. Everyone else doing work on qemu is using git (or svn).
Quoted 3 lines
Would we have synced up
releases of the two, or try to apply some ABI stability to libxc and libxenstore APIs to allow separate release of QEMU vs XenD tools ?
Releases of ioemu will follow releases of Xen, but commits will be made separately. So there will be at least some compatibility arrangements. I'm generally a fan of putting backward compatibility in interfaces, but I think for now we won't be making any promises.
Quoted 2 lines
The latter could be interesting because apps like Xenner are able
to use QEMU-DM in isolation from the rest of the XenD stack.
I certainly don't see any reason to go out of my way to prevent that :-).
Ian.
Quoted 8 lines · Ian Jackson
Daniel P. Berrange writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
What are your plans wrt to QEMU longer term ? Are you going to merge this GIT repo into
tools/ioemuin xen-unstable.hg, or thinking its better to keep a separate tree on an ongoing basis ?No, I don't think it's practical to keep this tree in xen-unstable.hg. Everyone else doing work on qemu is using git (or svn).
That's the answer I was hoping for - I much prefer each component to have its own source tree if the dependancies are clear-cut and managable separately. Indeed in my ideal universe, every main component under the tools/ directory in xen-unstable.hg would be independant!
Quoted 8 lines
Quoted 3 lines
Would we have synced up
releases of the two, or try to apply some ABI stability to libxc and libxenstore APIs to allow separate release of QEMU vs XenD tools ?Releases of ioemu will follow releases of Xen, but commits will be made separately. So there will be at least some compatibility arrangements. I'm generally a fan of putting backward compatibility in interfaces, but I think for now we won't be making any promises.
Great, that sounds like a good way to move forward, improving the maintainability of the QEMU / ioemu codebase.
Regards,
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Quoted 8 lines · Ian Jackson
Daniel P. Berrange writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
What are your plans wrt to QEMU longer term ? Are you going to merge this GIT repo into
tools/ioemuin xen-unstable.hg, or thinking its better to keep a separate tree on an ongoing basis ?No, I don't think it's practical to keep this tree in xen-unstable.hg. Everyone else doing work on qemu is using git (or svn).
Could we host a (read-only) hg mirror on xenbits.xensource.com, though? All of our tools are built around .hg, and we're in no place to handle an extra git tree.
regards
john
John Levon writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
Could we host a (read-only) hg mirror on xenbits.xensource.com, though? All of our tools are built around .hg, and we're in no place to handle an extra git tree.
Yes, absolutely.
(I haven't looked at the tools available for doing this, to check whether it's actually possible. If you have any references to hand to pass them on; failing that I'll get around to it shortly ...)
Ian.
Quoted 10 lines · Ian Jackson
John Levon writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
Could we host a (read-only) hg mirror on xenbits.xensource.com, though? All of our tools are built around .hg, and we're in no place to handle an extra git tree.
Yes, absolutely.
(I haven't looked at the tools available for doing this, to check whether it's actually possible. If you have any references to hand to pass them on; failing that I'll get around to it shortly ...)
A couple of options I know of offhand..
The 'convert' extension to sync from Git to Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension
There is also the Tailor program
http://progetti.arstecnica.it/tailor
I've not had experiance with using either for the Git -> Mercurial direction though, so not sure which will work best for Xen's needs.
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Quoted 16 lines · Daniel P. Berrange
Quoted 10 lines · Ian Jackson
John Levon writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
Could we host a (read-only) hg mirror on xenbits.xensource.com, though? All of our tools are built around .hg, and we're in no place to handle an extra git tree.
Yes, absolutely.
(I haven't looked at the tools available for doing this, to check whether it's actually possible. If you have any references to hand to pass them on; failing that I'll get around to it shortly ...)
A couple of options I know of offhand..
The 'convert' extension to sync from Git to Mercurial
Quoted 8 lines
http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension
There is also the Tailor program
http://progetti.arstecnica.it/tailor
I've not had experiance with using either for the Git -> Mercurial direction though, so not sure which will work best for Xen's needs.
I'd strongly recommend the convert extension. Tailor is harder to configure, slower, and last I checked did horrible things to the changelog DAG. The convert extension is what maintains
http://kernel.org/hg/linux-2.6.
Quoted 3 lines · Ian Jackson
I agree with Kevin Wolf's comments. But I would go further: why can this not be done by the code in xend which starts qemu-dm ? That would avoid any change to the qemu code.
I think that my implementation is more safety way because of the following reason.
qemu-dm can easily restart ioemu-logger when ioemu-logger die. And ioemu-logger death doesn't affected to guest software.
In addition:
We developed ioemu-logger without changing the codes which write messages. This enables less changes of the codes in qemu-dm.
--
Yuji Shimada
Quoted 4 lines · Yuji Shimada
Quoted 3 lines · Ian Jackson
I agree with Kevin Wolf's comments. But I would go further: why can this not be done by the code in xend which starts qemu-dm ? That would avoid any change to the qemu code.
Right, that would be even better.
Or maybe as another option, introduce proper logging functions instead of fprintf on stderr into (upstream) qemu. This would be the most work, of course, but IMHO also the cleanest solution.
Quoted 5 lines
I think that my implementation is more safety way because of the following reason.
qemu-dm can easily restart ioemu-logger when ioemu-logger die. And ioemu-logger death doesn't affected to guest software.
ioemu-logger is so simple that it would be a shame to see it crash anyway.
Quoted 4 lines
In addition:
We developed ioemu-logger without changing the codes which write messages. This enables less changes of the codes in qemu-dm.
You could do the same from within qemu-dm or in xend.
Kevin
Kevin Wolf writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
Or maybe as another option, introduce proper logging functions instead of fprintf on stderr into (upstream) qemu. This would be the most work, of course, but IMHO also the cleanest solution.
Quite so.
Quoted 7 lines
Quoted 5 lines
I think that my implementation is more safety way because of the following reason.
qemu-dm can easily restart ioemu-logger when ioemu-logger die. And ioemu-logger death doesn't affected to guest software.
ioemu-logger is so simple that it would be a shame to see it crash anyway.
I don't think there is any significant risk of xend dying because it can't write one of these logs. xend does lots of logging already of course.
Ian.
I agree with developing proper logging functions. But without these functions, I think ioemu-logger is a good solution.
We can reboot xend by the following command.
# /etc/init.d/xend restart Running of guest domains must not be affected by rebooting xend.
I'm sure that ioemu-logger dying is rare case. But there is no guarantee that it doesn't die.
If xend starts ioemu-logger, xend loses one end of a pipe by rebooting xend. After that, xend can't associates stdin for ioemu-logger with the pipe when xend restarts ioemu-logger after ioemu-logger dies. This problem happens because the life cycle of xend and qemu-dm is different. So I think to start ioemu-logger by qemu-dm is more simple.
Using named pipe (FIFO), it's possible to start ioemu-logger by xend. But sorry, I don't know about python well. Could anyone develope it?
Thanks.
--
Yuji Shimada
Quoted 20 lines · On Fri, 27 Jun 2008 14:40:58 +0100 Ian Jackson <[email protected]>…
Kevin Wolf writes ("Re: [Xen-devel] [PATCH] Log qemu-dm's message with date, time and pid"):
Quoted 3 lines
Or maybe as another option, introduce proper logging functions instead of fprintf on stderr into (upstream) qemu. This would be the most work, of course, but IMHO also the cleanest solution.
Quite so.
Quoted 7 lines
Quoted 5 lines
I think that my implementation is more safety way because of the following reason.
qemu-dm can easily restart ioemu-logger when ioemu-logger die. And ioemu-logger death doesn't affected to guest software.
ioemu-logger is so simple that it would be a shame to see it crash anyway.
I don't think there is any significant risk of xend dying because it can't write one of these logs. xend does lots of logging already of course.
Ian.
Quoted 6 lines · Yuji Shimada
I agree with developing proper logging functions. But without these functions, I think ioemu-logger is a good solution.
We can reboot xend by the following command.
# /etc/init.d/xend restart Running of guest domains must not be affected by rebooting xend.
This seems to be a valid point.
Quoted 10 lines
I'm sure that ioemu-logger dying is rare case. But there is no guarantee that it doesn't die.
If xend starts ioemu-logger, xend loses one end of a pipe by rebooting xend. After that, xend can't associates stdin for ioemu-logger with the pipe when xend restarts ioemu-logger after ioemu-logger dies. This problem happens because the life cycle of xend and qemu-dm is different. So I think to start ioemu-logger by qemu-dm is more simple.Using named pipe (FIFO), it's possible to start ioemu-logger by xend. But sorry, I don't know about python well. Could anyone develope it?
I'm under the impression that you're completely missing my (and Ian's) point. Actually, I'm not talking about having ioemu-logger started by xend. I'm talking about not having ioemu-logger at all (at least not as a new external tool). Xen has already too many of these small tools, IMHO, and we shouldn't add even more to them without need.
So, please implement it in qemu-dm instead of an external tool, if xend is not possible.
Kevin
OK. I understand what you tell me. Thanks.
I'll consider about a new implementation. It is multithread or multiprocess programming for logs in qemu-dm without using an external tool (ioemu-logger).
Thanks.
--
Yuji Shimada
Quoted 31 lines · On Mon, 30 Jun 2008 11:45:45 +0200 Kevin Wolf <[email protected]> wrote:
Quoted 6 lines · Yuji Shimada
I agree with developing proper logging functions. But without these functions, I think ioemu-logger is a good solution.
We can reboot xend by the following command.
# /etc/init.d/xend restart Running of guest domains must not be affected by rebooting xend.This seems to be a valid point.
Quoted 10 lines
I'm sure that ioemu-logger dying is rare case. But there is no guarantee that it doesn't die.
If xend starts ioemu-logger, xend loses one end of a pipe by rebooting xend. After that, xend can't associates stdin for ioemu-logger with the pipe when xend restarts ioemu-logger after ioemu-logger dies. This problem happens because the life cycle of xend and qemu-dm is different. So I think to start ioemu-logger by qemu-dm is more simple.Using named pipe (FIFO), it's possible to start ioemu-logger by xend. But sorry, I don't know about python well. Could anyone develope it?
I'm under the impression that you're completely missing my (and Ian's) point. Actually, I'm not talking about having ioemu-logger started by xend. I'm talking about not having ioemu-logger at all (at least not as a new external tool). Xen has already too many of these small tools, IMHO, and we shouldn't add even more to them without need.
So, please implement it in qemu-dm instead of an external tool, if xend is not possible.
Kevin