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

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

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.

Wei.

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