From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGq6q-0002MZ-8b for qemu-devel@nongnu.org; Mon, 02 May 2011 06:12:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGq6p-000598-4t for qemu-devel@nongnu.org; Mon, 02 May 2011 06:12:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGq6o-000593-OW for qemu-devel@nongnu.org; Mon, 02 May 2011 06:12:07 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p42AC5AP026993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 May 2011 06:12:05 -0400 Date: Mon, 2 May 2011 13:12:00 +0300 From: Alon Levy Message-ID: <20110502101200.GG17629@playa.redhat.com> References: <1303979358-4421-1-git-send-email-alevy@redhat.com> <1303979358-4421-4-git-send-email-alevy@redhat.com> <4DBAAA92.60409@redhat.com> <20110429221944.GD13837@amber.local> <4DBE731E.1050905@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBE731E.1050905@redhat.com> Subject: Re: [Qemu-devel] debug logging (was: Re: [PATCHv2 3/4] qxl: add debug_cs and cmdlog_cs) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On Mon, May 02, 2011 at 11:02:22AM +0200, Gerd Hoffmann wrote: > 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? The thing with grepping is that it conflicts with using the monitor on stdout, which is why I wanted to use a chardev. And of course a chardev solves the need for grep (at least to get a coarse level - of course you still need to grep later). dbg_print takes care of making it standard to have a loglevel and prefix, sounds good, but I'd still like to know if it is acceptable to also redirect with -debug, I guess reusing the DeviceState then, instead of my added struct, so just letting DeviceState.debug_chardev == NULL by default, and settable with -debug ,id= > > cheers, > Gerd > >