[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |