[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] PATCH 16/20: add a generic logging API



On Fri, Jun 22, 2007 at 03:16:38AM +0100, Daniel P. Berrange wrote:
> This patch adds a generic API for drivers to log warning / debug / info 
> messages. The existing error APIs are not suitable for this purpose since
> each time you set an error, it clears the previous one. This adds a public
> API virSetLogFunc allowing applications to register a callback to receive
> log messages. If none is registered, they are sent to the big void. It
> adapts the QEMU driver to use this logging API instead of qemudLog and
> qemudDebug(). It makes the qemud/qemud.c file register a logging callback
> to receive the messages & send them onto syslog/stderr as needed.
> 
> There are other drivers (in particular src/xm_internal.c) where this
> logging API will be useful too. I've not attempted to make them use it
> yet though.
> 
>  include/libvirt/virterror.h |   24 ++++++++++++++++++
>  qemud/conf.c                |   46 ++++++++++++++++++------------------
>  qemud/driver.c              |   56 ++++++++++++++++++++++----------------------
>  qemud/iptables.c            |    8 +++---
>  qemud/qemud.c               |   36 ++++++++++++++++++++++++++++
>  qemud/uuid.c                |    9 +++----
>  src/internal.h              |    5 +++
>  src/libvirt_sym.version     |    1 
>  src/virterror.c             |   28 ++++++++++++++++++++++
>  9 files changed, 155 insertions(+), 58 deletions(-)

  Hum, I actually have a couple of issues with defining a new error logging
API without having discussed it before at least for a bit. I'm a bit worried
by by a few things about it:
    - it's only string level, okay that's functionally equivalent
      to a syslog, but I find that as an user API, having just a string
      is a bit problematic
    - it's the first callback kind of support we would actually export
      at a blessed API level, I would not rush this I guess we should be
      clear that reentrancy of libvirt API from that callback is not
      something we would support.

 Basically I would prefer if a subset version of that patch not changing
virterror.h could be applied to avoid blocking the reunification work.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]