|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command
>>> On 15.03.16 at 16:38, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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.
Quite possible, and all of what you write makes sense. Yet that
wasn't my intention here. I specifically put the string <-> number
mapping in xl, so it could be that (and only that, outside the
hypervisor itself) which gets changed if the hypervisor log levels
ever change. The tool could use version information or some
other detection mechanism to provide backwards compatibility
(and be independent of the precise hypervisor version it got
built in parallel with, if that's desired). And hence I specifically
made the interfaces dumb - raw numbers, with no meaning
assigned to their values.
And then, with what you describe I assume the current hypervisor
side implementation wouldn't be suitable anymore anyway, as the
translation between the interface exposed log levels and the
internally used ones would need to happen in the sysctl handler.
To me, all of this looks increasingly like over-engineering for a
very simple debugging aid (which is all the new command was
meant for). If you and Wei can settle on some alternative
implementation, I'm fine to accept that, but I don't think I'm
going to spend much more time on fiddling with any of the 3
patches. It's going to be sad though if even the serial console
based log level adjustment won't make it into 4.7, despite it
having got posted months ago (with this v2 just extending on
it).
Jan
> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |