On Fri, May 20, 2011 at 04:17:12PM +0530, Supriya Kannery wrote:
> On 05/20/2011 03:19 PM, Daniel P. Berrange wrote:
> >On Thu, May 19, 2011 at 12:19:11PM -0600, Eric Blake wrote:
> >>On 05/09/2011 01:07 AM, Supriya Kannery wrote:
> >>>
> >>>a. VIRSH_DEBUG=<log_level>
> >>> log_level can be a value between 0 - 4, where
> >>> 0 -> "ERROR"
> >>> 1 -> "WARNING"
> >>> 2 -> "NOTICE"
> >>> 3 -> "INFO"
> >>> 4 -> "DEBUG"
> >
> >This is exactly the opposite to LIBVIRT_DEBUG=<log level> which
> >has
> >
> > * 1: DEBUG
> > * 2: INFO
> > * 3: WARNING
> > * 4: ERROR
> >
> >IMHO, these need to be kept the same.
>
> Through out virsh.c, the vshDebug is called with the assumption that
> DEBUG=4 or 5. Also, any higher log level record than user specified
> log level, doesn't get displayed as per vshDebug() code. So there
> was no
> match between the enum definition and the code written.
> vshDebug(vshControl *ctl, int level, const char *format, ...)
> {
> ...
> vshOutputLogFile(ctl, 5, format, ap);
> va_end(ap);
>
> if (level > ctl->debug)
> return;
>
> va_start(ap, format);
> ...
> }
>
>
> When user choose "DEBUG", the expectation is that it is the superset
> of all log records. Usually, higher the log level value, more
> records are
> expected. I can try changing libvirt as well to align to this norm, if
> there are no major compatibility issues. Please comment.
We can't really change libvirt log level, IMHO, because it is too widely
used and thus changing it would cause endless confusion. Likewise I think
that if virsh used different log level numbers from libvirt, this will
cause confusion, so I think the only option is to make the virsh log levels
work in exactly the same way as existing libvirt code
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list