From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v2 3/3] xl: new "loglvl" command
Date: Tue, 15 Mar 2016 15:38:48 +0000 [thread overview]
Message-ID: <22248.11400.362158.234499@mariner.uk.xensource.com> (raw)
In-Reply-To: <56E8253E02000078000DC7E0@prv-mh.provo.novell.com>
Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
> Yes and no. If all of the sudden the hypervisor didn't have an "error"
> log level anymore, what would you do? Mapping "error" to "warning"
> wouldn't be right. Nor would mapping it to anything else. Correct
> behavior in that case would simply be failure, and it wouldn't seem
> too relevant to me at what layer that failure would get signaled.
I think you are looking at this the wrong way.
Log levels are primarily attributes of messages. Messages are
categorised by the hypervisor code into one of a set of levels. The
levels form a total order (which I'm going to call `boringness').
Every message has a level, too.
A request to set the log level to a particular value is a request for
the hypervisor to print all messages whose message level is no more as
`boring' than the requested log level.
If the hypervisor changes so as to abolish a level, that does not mean
that it is now nonsensical to request to set the log level to the
now-abolished value. It simply means that the set of messages at that
level becomes the empty set.
Likewise if the hypervisor changes so as to introduce a new level B
(such that A < B < C where A and C are existing levels), this simply
means that old code which doesn't know about B cannot specify
explicitly which of {A}, {A,B}, {A,B,C} it wants. When introducing B
we need to make a decision about whether old code which specified C
(ie show all messages of boringness at least C) should be treated as
having asked for B too. (Obviously old code which specified A will
get B.)
None of this depends on whether the levels are represented as strings
or atoms or numbers or whatever.
(I note that there is some confusion because the ordering is inverted.
That is, rather than messages having severities, and the log level
being a severity threshold; the primary question is log level
verbosity and messages have a boringness threshold. Most other log
level systems assign larger level numbers to more interesting
messages. I am goong to continue to work with the existing sense of
the numerical level parameter because inverting it now will be
confusing.)
I would like to propose the following scheme:
* Multiply, right now, as a one-off ABI change, all the hypervisor
message levels by (let us say) 100, and add (say) 10000. So
error 10100
warning 10200
info 10300
debug 10400
* Declare that the hypervisor ABI is stable in this area. The
hypercall provides the hypervisor with a number (the log level) and
the hypervisor will print all messages whose message level number
is no larger than the specified log level number.
* Change all existing tools and user-facing interfaces[1] which set
the log level to convert string-to-number using a table which, in
its initial form, is identical to the message level enum but with
50 added to each value. This table also has the "none" and "all"
entries:
all 2147483647 [no messages must ever have such a high boringess]
error 10150
warning 10250
info 10350
debug 10450
none 0
[1] This includes both the hypervisor command line and libxl.
The log level request enum becumes a libxl idl enum, too.
We do NOT provide the actual message level numerical values outside
hypervisor code.
* When we remove a level, we remove its enum definition in the
hypervisor code, so that we can be sure that code remains which
generates the removed level. But we retain its name in the
string-to-number table, for the benefit of old users. Eventually
we can make use of the old name produce a warning, and even later,
we can remove the name.
* When we introduce a level, we assign it a new number. We assign
it either +25 or +75, according to whether we want the new level
to count as the lower of the two old levels for naive programs,
or as the higher. Eg:
To introduce "notice" To introduce "notice"
which old "warning" excludes: which old "warning" includes:
[in message level enum:] [in message level enum:]
warning 10200 warning 10200
+ notice 10275 + notice 10225
info 10300 info 10300
[in string-to-level table:] [in string-to-level table:]
info 10350 info 10350
+ notice 10287 + notice 10212
warning 10250 warning 10250
If we do not want to be able to decide, when we introduce a new log
level, which way the "old callers" decision goes, then the
requested level string-to-number table and the hypervisor message
generation level enum can have identical numerical values.
That would be simpler, and would retain a good degree of backward
compatibility.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-15 15:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 16:38 [PATCH v2 0/3] allow runtime log level threshold adjustments Jan Beulich
2016-03-04 16:46 ` [PATCH v2 1/3] console: allow " Jan Beulich
2016-03-04 20:55 ` Konrad Rzeszutek Wilk
2016-03-07 10:44 ` Jan Beulich
2016-03-07 14:41 ` Konrad Rzeszutek Wilk
2016-03-07 15:19 ` Jan Beulich
2016-03-04 16:47 ` [PATCH v2 2/3] libxc: wrapper for log level sysctl Jan Beulich
2016-03-05 16:00 ` Dario Faggioli
2016-03-08 16:20 ` Wei Liu
2016-03-04 16:48 ` [PATCH v2 3/3] xl: new "loglvl" command Jan Beulich
2016-03-04 18:45 ` Dario Faggioli
2016-03-07 11:46 ` Jan Beulich
2016-03-07 18:07 ` Dario Faggioli
2016-03-08 8:08 ` Jan Beulich
2016-03-08 14:05 ` George Dunlap
2016-03-08 16:09 ` Wei Liu
2016-03-08 18:05 ` Dario Faggioli
2016-03-05 15:36 ` Dario Faggioli
2016-03-07 13:20 ` Fabio Fantoni
2016-03-07 13:26 ` Jan Beulich
2016-03-08 16:20 ` Wei Liu
2016-03-14 15:23 ` Jan Beulich
2016-03-14 15:36 ` Wei Liu
2016-03-14 15:49 ` Jan Beulich
2016-03-14 16:01 ` Wei Liu
2016-03-14 17:00 ` Jan Beulich
2016-03-14 17:07 ` Ian Jackson
2016-03-15 7:37 ` Jan Beulich
2016-03-15 13:58 ` Wei Liu
2016-03-15 14:07 ` Jan Beulich
2016-03-15 14:51 ` Wei Liu
2016-03-15 15:03 ` Jan Beulich
2016-03-15 15:38 ` Ian Jackson [this message]
2016-03-16 11:22 ` Jan Beulich
2016-04-28 15:33 ` Wei Liu
2016-04-29 7:20 ` Jan Beulich
2016-05-02 11:14 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22248.11400.362158.234499@mariner.uk.xensource.com \
--to=ian.jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).