WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH - resend] addition of loglevel for printf in Xen

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH - resend] addition of loglevel for printf in Xen HV
From: Steven Rostedt <srostedt@xxxxxxxxxx>
Date: Thu, 26 Oct 2006 11:16:46 -0400
Cc: chrisw@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 26 Oct 2006 08:17:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C166827A.353E%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C166827A.353E%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (X11/20060614)
Keir Fraser wrote:


I think yet-another-little-tool in dom0 is the right way to go. We can add a
sysctl to get/set the parameters. It can pretty-print the current parameters
and also provide a way of changing them. I don't think there's any benefit
to integration with xm -- it's not like this needs to be integrated with
xend or anything like that.

That should be easy enough. What's the best way to communicate between dom0 and the HV? Add a hypercall for this?


Yes, we should also have a way to set them as a boot parameter. I suggest we
should only enact those explicit parameters when dom0 starts to boot though
(no need to stop Xen being noisy in initial boot). We could have an extra
parameter (e.g., 'quiet') to override that if someone really cares.

Yeah, but this can be handled after the initial work is done.


It'd be nice to have debug-key support for changing it too, but actually
that's probably not so important if we have the dom0 tool.

My original patch included a debug key for log level. I'm sure it won't be too hard to add something to change the thresholds too. (for those that only communicate to the machine via a serial console).


Everything you said I agree with, so please do go hack it up. :-)

Thanks!  Will start hacking!


Another thought... By pushing the rate-limiting into printk() itself, we
lose the ability to print all-or-nothing for related blocks of printk (e.g.,
register dumps). We might want a 'same as previous line' specifier, which
would print/not-print same as previous output line?


Hmm, I wonder if we should have a XENLOG_CRASH level which is above XENLOG_ERR. This will be when the system is actually taking a dump, and we want to show everything. Or just simply force the thresholds to max just before showing the crash print outputs. Or add a variable to know we are in the process of crashing, and have printk ignore the print rate limit if that's the case, similar to the oops_in_progress of Linux.

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel