All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cedric Bosdonnat <cbosdonnat@suse.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: per-domain logging
Date: Mon, 10 Oct 2016 09:03:49 +0200	[thread overview]
Message-ID: <1476083029.2856.3.camel@suse.com> (raw)
In-Reply-To: <20161007140916.GK3687@citrix.com>

On Fri, 2016-10-07 at 15:09 +0100, Wei Liu wrote:
> Instead of trying to change all the format strings I think it would be
> better to have a new set of LOG macros that takes domid.
> 
> Something like:
>   LOGEVD(ERROR, errno, domid, "xxxx");

Sounds good to me, even if LOGEVD will just concatenate something like
"Domain %d: " to the "xxxx". At least this would be much cleaner in the
libxl code

> I would also like to have the log format written down in some document
> or header file.

You mean as a documentation? That would be in libxl, not in xtl, right?
We could have a comment above the LOG*D macros explaining what the message
will look like (Prepending 'Domain %d: " to the message passed to normal log
functions). And a comment on top of the current functions explaining all the
different things that are passed on to xtl.

> But let's step back a bit: have we agreed on the approach forward? This
> thread doesn't seem to have a clear conclusion yet.  Obviously I don't
> want you to waste your writing code that's going to be threw away.

I don't want to loose time either, but sometimes it's better to write some
code to check that what we are mentioning is possible.

> If you're happy with demuxing in libvirt, I won't object to it. Looks
> like there is relatively less code churn involved than other solutions,
> say, libxl keeping track of a set of per-domain xtl loggers.

Having a set of per-domain xtl logger is also possible, but with one logger
demuxing all messages, it's fairly easy to support both old log format
and new ones. And the format we get in the callbacks from libxl is something
like "%s%s%s%s%s", with things like file, line, function and message. Thus
adding a domain in there doesn't make much sense. I'ld more in favor of the
LOG*D family in libxl.

--
Cedric

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

  parent reply	other threads:[~2016-10-10  7:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14 14:22 per-domain logging Cedric Bosdonnat
2016-09-15 14:50 ` Wei Liu
2016-09-15 15:11   ` Wei Liu
2016-09-15 15:41     ` Cedric Bosdonnat
2016-09-19 15:23       ` Ian Jackson
2016-09-19 16:53         ` Konrad Rzeszutek Wilk
2016-10-04  9:14         ` Cedric Bosdonnat
2016-10-07 14:09           ` Wei Liu
2016-10-07 15:37             ` Ian Jackson
2016-10-10  7:05               ` Cedric Bosdonnat
2016-10-10  7:03             ` Cedric Bosdonnat [this message]
2016-10-10 10:06               ` Wei Liu
2016-10-13  9:28                 ` Cedric Bosdonnat
2016-10-13  9:41                   ` Wei Liu
2016-11-09 10:27                     ` Cedric Bosdonnat
2016-11-11  1:51                       ` Wei Liu
2016-11-11 11:22                       ` Ian Jackson

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=1476083029.2856.3.camel@suse.com \
    --to=cbosdonnat@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.