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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.03.16 at 14:58, <wei.liu2@xxxxxxxxxx> wrote:
> On Tue, Mar 15, 2016 at 01:37:39AM -0600, Jan Beulich wrote:
>> >>> On 14.03.16 at 18:07, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
>> >> They could become more fine grained (for example, Linux has a
>> >> few more than we have now). And the string/number correlation
>> >> is an implementation detail anyway.
>> > 
>> > Could we solve that problem by multiplying the numbers by 10 ?
>> 
>> That particular one probably yes, but who knows what else
>> adjustments there might be in the future. Plus - which layer
>> would you see do the transformation back then? Hypervisor?
>> libxc? In the end all speaks for passing around strings all the
>> way down to the hypervisor then, however ugly I may
>> consider such...
> 
> The constraint is that we can't delete log levels in libxl  once it is
> exposed to application. If the hypervisor log level changes (especially
> in case of deletion) we need to map the old one to new one. With that
> in mind it make more sense to have the transformation layer in libxl.
> 
> Note that passing a string down won't give us benefit with regard to
> maintaining backward compatibility -- there still needs to be a
> compatibility shim somewhere in the event of deletion, so we might just
> do it in libxl.
> 
> Does this make sense?

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.

> BTW I can take over the toolstack part for you if we reach agreement on
> how to proceed. I think you've had enough stuff on your plate now. It
> would be easier for me to write toolstack code and save both us some
> time.

Oh, thanks a lot, I would much appreciate that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel