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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 20/10/06 20:23, "Steven Rostedt" <srostedt@xxxxxxxxxx> wrote:

> This patch really does need to go in.  Whether in its current form, or
> modified greatly.  The ability to give the developer a level of printing
> is a great asset.  That is why Linux has this ability.

I agree. Here are some comments:

 * We don't need 8 log levels. Noone knows the difference between
EMERG/CRIT/ALERT, or at least I really doubt that they can be used
consistently in a large code base. I suggest:
    XENLOG_ERR    -- Bad errors, likely fatal (to a guest or the host)
    XENLOG_WARN   -- Weird stuff happening, recoverable (maybe)
    XENLOG_INFO   -- Interesting info, not too noisy
    XENLOG_DEBUG  -- Noisy as you like

 * I think your ratelimit stuff could be usefully integrated. Instead of
having a single threshold, have two: one above which everything is printed,
one below which nothing is printed. In between is rate limited.

 * I think the guest/not-guest printing is orthogonal to the log-level
scale. Perhaps we should have another <> specifier (<G>?) that can be used
alongside a log level specifier. This would give another two threshold
values (two for guest, two for non-guest) which would maybe be overkill but
would be reasonable if we gave a dom0 tool to control it. Actually this
could be extended to other subsystems (shadow code for example). Then we
would have a control per subsystem falling back to default thresholds if not
specified. That probably really is overkill!

 * Likely defaults:
      Non-guest prints ERR/WARN always, no INFO/DEBUG
      Guest prints ERR/WARN rate-limited, no INFO/DEBUG
      (Like Linux, we'd probably have slacker default controls until initial
bootstrap has completed, so you get useful info out).

What do you think?

 -- Keir



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