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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 15, 2016 at 08:07:42AM -0600, Jan Beulich wrote:
> >>> 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.
> 

OK, so my thought was that application should continue to work. First we
can't break compilation of applications, second we should make it
continue to function whenever possible.

The first requirement is easy, using either number or string works the
same.

As for the second, I was thinking about downgrading or upgrading to a
different log level -- what would you do to the hypervisor command line
option guest_loglvl if one of the log levels is gone? Do you just crash
xen or setting log level to some other value? I think libxl can follow
this same principle.

But then you are of the opinion that it should just return error if one
log level is gone -- I think this is probably fine too , we just need to
document the semantics the API.

Wei.

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