qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] debug logging (was: Re: [PATCHv2 3/4] qxl: add debug_cs and


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]