xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v2 3/3] xl: new "loglvl" command
Date: Tue, 15 Mar 2016 08:07:42 -0600	[thread overview]
Message-ID: <56E8253E02000078000DC7E0@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160315135851.GE31759@citrix.com>

>>> On 15.03.16 at 14:58, <wei.liu2@citrix.com> wrote:
> On Tue, Mar 15, 2016 at 01:37:39AM -0600, Jan Beulich wrote:
>> >>> On 14.03.16 at 18:07, <Ian.Jackson@eu.citrix.com> 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.

> 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@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-03-15 14:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 16:38 [PATCH v2 0/3] allow runtime log level threshold adjustments Jan Beulich
2016-03-04 16:46 ` [PATCH v2 1/3] console: allow " Jan Beulich
2016-03-04 20:55   ` Konrad Rzeszutek Wilk
2016-03-07 10:44     ` Jan Beulich
2016-03-07 14:41       ` Konrad Rzeszutek Wilk
2016-03-07 15:19         ` Jan Beulich
2016-03-04 16:47 ` [PATCH v2 2/3] libxc: wrapper for log level sysctl Jan Beulich
2016-03-05 16:00   ` Dario Faggioli
2016-03-08 16:20   ` Wei Liu
2016-03-04 16:48 ` [PATCH v2 3/3] xl: new "loglvl" command Jan Beulich
2016-03-04 18:45   ` Dario Faggioli
2016-03-07 11:46     ` Jan Beulich
2016-03-07 18:07       ` Dario Faggioli
2016-03-08  8:08         ` Jan Beulich
2016-03-08 14:05           ` George Dunlap
2016-03-08 16:09             ` Wei Liu
2016-03-08 18:05             ` Dario Faggioli
2016-03-05 15:36   ` Dario Faggioli
2016-03-07 13:20   ` Fabio Fantoni
2016-03-07 13:26     ` Jan Beulich
2016-03-08 16:20   ` Wei Liu
2016-03-14 15:23     ` Jan Beulich
2016-03-14 15:36       ` Wei Liu
2016-03-14 15:49         ` Jan Beulich
2016-03-14 16:01           ` Wei Liu
2016-03-14 17:00             ` Jan Beulich
2016-03-14 17:07               ` Ian Jackson
2016-03-15  7:37                 ` Jan Beulich
2016-03-15 13:58                   ` Wei Liu
2016-03-15 14:07                     ` Jan Beulich [this message]
2016-03-15 14:51                       ` Wei Liu
2016-03-15 15:03                         ` Jan Beulich
2016-03-15 15:38                       ` Ian Jackson
2016-03-16 11:22                         ` Jan Beulich
2016-04-28 15:33                           ` Wei Liu
2016-04-29  7:20                             ` Jan Beulich
2016-05-02 11:14                               ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E8253E02000078000DC7E0@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).