On Mon, 2016-03-07 at 04:46 -0700, Jan Beulich wrote:
> > > > On 04.03.16 at 19:45, <dario.faggioli@citrix.com> wrote:
> > On Fri, 2016-03-04 at 09:48 -0700, Jan Beulich wrote:

> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
> > >      return 0;
> > >  }
> > >  
> > > +int libxl_log_level(libxl_ctx *ctx, bool set, bool guest,
> > > +                    int *lower_thresh, int *upper_thresh)
> > > +{
> > > +    int ret;
> > > 
> > As per libxl coding style, this wants to be 'r'.
> This and everything else below look to be valid comments, but
> it's rather frustrating that simply cloning an existing function (I
> user the debug key ones as basis) doesn't give me valid code,
> the more that I did scroll up and down a few pages to see
> whether I just happened to pick a particularly bad example.
>
Hehe, but do you understand that, saying this, you're making it very
likely that people will ask *you* to fix libxl_send_debug_keys() --and
perhaps more tool side code? :-P :-P

No, jokes apart, I agree that inconsistency is a real bad thing... but
it's an hard fight, and we do have examples spread all around the
source code (both Xen and tools), AFAICT.

I run into the patch, decided to have a look, and thought I better say
what I found, with the aim of fighting exactly that (inconsistency in
the code). If there is anything else I can do for help, feel free to
ask (e.g., I guess I can send a patch to fix style of
libxl_send_debug_keys() myself :-)).

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)