|
From: | Gerd Hoffmann |
Subject: | [Qemu-devel] debug logging (was: Re: [PATCHv2 3/4] qxl: add debug_cs and cmdlog_cs) |
Date: | Mon, 02 May 2011 11:02:22 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110318 Red Hat/3.1.9-3.el6_0 Thunderbird/3.1.9 |
Hi,
The bigger hack called "qxl_terse" I didn't even send :) ok, so now I get to either keep this in my closet or think of how to do a minimal acceptable qemu logging infrastructure that would let me register a logging handle and use that to redirect to a chardev (they would all default to being muxed over stdio?) QemuLogger *qemu_create_logger(const char *logger_id); - logger_id is used to match to the chardev given on the command line - need to prevent collision, so probably easier to have a logger_id be an int and have that looked up to a string in an automatically generated table?
What I have in mind is a simple dbg_print() function, integrated with qdev and simliar to what the linux kernel has, i.e. something like:
int dbg_print(DeviceState *qdev, int loglevel, const char *fmt, ...);This can basically be used that as drop-in replacement for the fprintf(stderr, fmt, ...) style found in many drivers.
dbg_print would get the driver name via qdev->info->name, get the instance via qdev->parent_bus->info->get_dev_path(), get a timestamp, then create a standard prefix for all messages for easy grepping. It would also check qdev->loglevel to figure whenever the message should be printed or not. All devices get a property to set qdev->loglevel, so all logging can be configured at runtime per device.
Messages go to stderr by default. A -debug switch could be added to route them another way.
Comments in the idea? cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |