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

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Apr 29, 2016 at 01:20:57AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 17:33, <wei.liu2@citrix.com> wrote:
> > On Wed, Mar 16, 2016 at 05:22:27AM -0600, Jan Beulich wrote:
> >> >>> On 15.03.16 at 16:38, <Ian.Jackson@eu.citrix.com> 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).
> > 
> > If this is just a debugging aid and not intending to be consumed by high
> > level toolstack, maybe we can make a dedicated helper program? We
> > already have a bunch of those. Should the need really arises we can
> > then consider making it proper stable API / ABI.
> 
> That's an option, albeit a slightly awkward one. This new thing
> really fits well with the debug-key and dmesg sub-commands,
> which both are there just for debugging, too.
> 

This is a good argument. I'm fine with treating it like debug-key and
dmesg.

Ian?

Wei.

> Jan
> 

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