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 09:30:27 -0400
Cc: chrisw@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 26 Oct 2006 06:31:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C165057F.34A2%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: <C165057F.34A2%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (X11/20060614)
Keir Fraser wrote:


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:

Keir, Thanks for the comments, they are very useful.


 * 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

Perfectly agree. Four is fine, especially if we implement a <G> option for guest.


 * 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'm not quite sure I understand this fully.

So what you are saying is instead of having the print_log_level have a printk_upper_log_level and a printk_lower_log_level where, as you say, everything below the printk_lower_log_level is printed, and the printk_upper_log_level where everyting above is not printed, and thus everything in between is rate limited? (remember 0 is ERR and 3 is DEBUG)



 * 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?


I have to admit I like the ideas you have thrown to me.

So let me put this is my own words/code so that you can see what my view of this is.

Have 4 thresholds.

printk_dom0_upper_threshold
printk_dom0_lower_threshold
printk_guest_upper_threshold
printk_guest_lower_threshold

Have 4 log levels:

XENLOG_ERR
XENLOG_WARN
XENLOG_INFO
XENLOG_DEBUG

Add a XENLOG_GUEST (defined as "<G>")

And for less typing add

XENLOG_G_ERR
XENLOG_G_WARN
XENLOG_G_INFO
XENLOG_G_DEBUG

which would just append the XENLOG_GUEST in front of the associated warning.

example;

   printk(XENLOG_G_ERR "fatal error in guest\n");

   printk(XENLOG_INFO "dom0 is running happily\n");


Then in printk itself, we would have

  upper_thresh = printk_dom0_upper_threshold;
  lower_thresh = printk_dom0_lower_threshold;
  level = some_default;

  if (strncmp("<G>",fmt,3)==0) {
        upper_thresh = printk_guest_upper_threshold;
        lower_thresh = printk_guest_lower_threshold;
        level = some_guest_default;
        fmt += 3;
  }
  if (strncmp("<[0-3]>",fmt,3)==0) {  /* using regexpr and not C to make
                                         this readable */
        level =~ s/<(0-3)>/$1/;  /* perl format :-) */
  }

  if (level > upper_thresh)
        return; /* do nothing */

  if (level >= lower_thresh)
        if (rate_limit())
                return;

  print as normal.


So anything in between the upper and lower thresholds inclusive would be rate limited. Also I'm not sure of the best way dom0 can communicate threshold changes to the hypervisor. As well as if there should be a config to set the defaults.

So what are your thoughts?

-- Steve

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