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 Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel