|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH - resend] addition of loglevel for printf in Xen
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
|
|
|
|
|