[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 28.04.16 at 17:33, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Mar 16, 2016 at 05:22:27AM -0600, Jan Beulich wrote:
>> >>> 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).
> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.