On 08/09/2013 11:04 AM, Daniel P. Berrange wrote: > On Fri, Aug 09, 2013 at 10:56:41AM -0600, Eric Blake wrote: >> On 08/09/2013 10:50 AM, Daniel P. Berrange wrote: >> >>>> I should have looked at the xen code closer. Seems libxl doesn't cope >>>> well with a NULL logger :(. >>>> >>>> Hmm, should the logger for this driver-wide ctx (used for getting libxl >>>> version and the like, no domain ops) just dump messages to /dev/null or >>>> should they go to a driver-wide log file? >>> >>> Depends if you think there's any useful info to be had from the >>> driver wide context object ? If so, then probably best to have a >>> driver-wide log file for those messages >> >> Or even just reply the data into the main libvirtd.log (ie. use existing >> virLog functionality, rather than creating a new file), since ideally >> the log will be relatively sparse: in my case, it would be just one >> message stating that libxl is not available, at which point the libxl >> driver no longer does anything else during the life of libvirtd. > > I was going to suggest that, but IIUC, the libxl logger API requires > you to give it a FILE * instance to which it writes directly. To feed > it into our normal logs, we'd want it to let us give it a callback > for writing log messages. Can we rely on open_memstream() being present on any platform with libxl? If so, that would give us a FILE* interface to libxl, while still giving us access to the strings it prints which we can then turn around and hand to our logger. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list