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

RE: [Xen-devel] [PATCH] tools: ocaml: fix the logging in the ocaml libxl bindings



On Thu, 2011-03-31 at 23:57 +0100, Dave Scott wrote:
> Hi,
> 
> > David Scott writes ("[Xen-devel] [PATCH] tools: ocaml: fix the logging
> > in the ocaml libxl bindings"):
> > > tools: ocaml: fix the logging in the ocaml libxl bindings.
> [ snip ]
> 
> Ian Jackson replied:
> > Thanks, but:
> > 
> >  * Can you make a version where the line lengths do not exceed 75 ?
> >    That allows for a patch +/- column, plus a couple of levels of
> >    quoting, to fit in an 80-column window.
> 
> Will do. I think I've got into a habit of writing very long lines.
> I blame my poor choice in editors and email clients :-)

I blame your massive widescreen monitor ;-)

> 
> >  * Now that I read this code I'm very confused.  Why does log_vmessage
> >    not actually output the message anywhere ?  Looking at the code,
> >    the buffer is printed out only if the call fails (I assume that's
> >    what failwith_xl is).  That's not right.  What about debugging
> >    output ?
> > 
> >    There is no guarantee that the logger will be called to report any
> >    particular number of messages if a libxl call fails.  Specifically,
> >    it may output zero error messages, or several one, before returning
> >    a failure code.  And it will frequently output a number of
> >    informational messages.
> 
> That is indeed the current behaviour -- most log messages end up dropped,
> only those which are in the buffer when the libxl call fails get bubbled
> up to the user in an exception. The main difference after my patch is
> that the code nolonger segfaults after calling (IIRC) gettopologyinfo 
> and hopefully won't blow its buffer if the logging ever gets spammy :-)
> 
> If you recommend changing the policy to always record/handle all log 
> messages then that sounds fine to me. From the point of view of the 
> ocaml code I can think of the following options (Vincent: do you have any
> advice?):
> 
> 1. add the notion of a per-call context to the ocaml and associate 
>    logging callbacks with this. The ocaml code can then do whatever it 
>    likes on a per-call basis.
> 
> 2. allow the ocaml to set a global logging callback which would handle
>    logging from all ocaml xl calls in the same process
> 
> 3. allow the ocaml to set some syslog logging parameters so all ocaml xl
>    calls would just log via syslog
> 
> I don't think any of these are particularly complicated. Anyone have any
> thoughts / recommendations / preferences / suggestions?

Somewhat of an aside but what do you think of having libxl contexts with
longer lifespans than the current one per libxl call model? e.g. you
would open a context in ocaml code, make a series of calls and then
close it? Or perhaps even keep it for the lifetime of a domain or a
thread of processing context etc?

Ian.

> 
> Cheers,
> Dave
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.