From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: [PATCH - resend] addition of loglevel for printf in Xen HV Date: Thu, 26 Oct 2006 11:16:46 -0400 Message-ID: <4540D15E.6020901@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: chrisw@sous-sol.org, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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