I think this would be useful.

As discussed on IRC, won't get done until mid Jan (by me)
but if you want to have a go at a patch then be my guest.

More thoughts on this issue:

Currently g->log_message_cb will only see messages sent by
the daemon to the VM console.  If g->verbose is set, then
these messages are *also* printed to stderr (as well as being
sent to the g->log_message_cb handler if any).

Some types of message that g->log_message_cb would never see:

 * extra debug from the library when g->verbose is set
 * trace messages (LIBGUESTFS_TRACE=1: these go to stderr)
 * debug from other things that use the guestfs_get_verbose
   call, eg. capitests, guestfish

So g->log_message_cb is not very useful.  At the same time
there is obviously a need to be able to capture debug and
trace messages separately in GUI programs
(guestfs-browser, BoxGrinder and RHEV-M all need it).

We cannot change g->log_message_cb, because of the ABI contract.

I will think about some alternate way and post about it on the
mailing list.

(In reply to comment #2)
> I will think about some alternate way and post about it on the
> mailing list.

https://www.redhat.com/archives/libguestfs/2010-December/msg00081.html

Interim patch posted for review here:

https://www.redhat.com/archives/libguestfs/2011-March/msg00036.html

Full patch series including Ruby bindings posted:
https://www.redhat.com/archives/libguestfs/2011-March/msg00060.html

One aspect that is broken is that the Ruby interpreter segfaults
if the callback raises any sort of exception.  Apparently one
can prevent this using the 'rb_rescue' function, but I have yet
to find a coherent explanation of how exactly to use this.

Hey Rich,
     While the rb_* calls can be a bit dense, in the end they are relatively easy to use.  rb_rescue in particular takes exactly 4 arguments: the function that you want to call, the (single) argument to that function, the function to call if the original function throws an exception, and the (single) argument to the rescue function.  If you compile and run the below example, the first call to rb_rescue() calls cb, which succeeds without doing much, so only "Hello from cb" is printed.  The second call to rb_rescue() calls cb, which then raises an exception, at which point rescue() is called to do cleanup work.  You can compile the program with: gcc -g -Wall test.c -I/usr/lib64/ruby/1.8/x86_64-linux -lruby

#include <stdio.h>
#include <stdlib.h>

#include <ruby.h>

static VALUE cb(VALUE args)
{
  fprintf(stderr, "Hello from cb\n");
  if (TYPE(args) != T_FIXNUM)
    rb_raise(rb_eTypeError, "expected a number");
  return Qnil;
}

static VALUE rescue(VALUE args, VALUE exception_object)
{
  fprintf(stderr, "Rescue args %s, object classname %s\n",
          StringValueCStr(args),
  	  rb_obj_classname(exception_object));

  return Qnil;
}

int main()
{
  int r;

  ruby_init();

  r = rb_rescue(cb, INT2NUM(0), rescue, rb_str_new2("data"));
  r = rb_rescue(cb, rb_str_new2("bad"), rescue, rb_str_new2("data"));

  return 0;
}

Upstream (with broken exception handling):
http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=6a64114929a0b098f5a1e31e17e7802127925007

Thanks Chris; Ruby exceptions are fixed now too:

http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=e751293e10d5ecbb2ef43a61b9c153a1fc4f0304