Re: per-domain logging

[Cedric Bosdonnat <cbosdonnat@suse.com>]

Hi Wei, Ian,

In quite a number of places, the domid we have in the function calling LOG*
may be the one of a stubdom. In the log we want to output the domid of the
domain the user knows about. Would there be a way to get it?

An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting
that domid may not be the real domain id. An I wonder if there are other
places where domid may be the one of a stubdom and I don't know it.

--
Cedric

On Mon, 2016-10-10 at 11:06 +0100, Wei Liu wrote:
> On Mon, Oct 10, 2016 at 09:03:49AM +0200, Cedric Bosdonnat wrote:
> > 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.
> > 
> 
> 
> Presumably you will define LOG*D variants in libxl_internal.h, I think a
> comment there right before those macros will be good enough.
> 
> > > 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.
> > 
> 
> 
> Sure, fine by me.
> 
> Wei.
> 
> > --
> > Cedric
> 
> 
> 

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