Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel