Re: [PATCH v2 3/3] xl: new "loglvl" command

["Jan Beulich" <JBeulich@suse.com>]

>>> On 14.03.16 at 16:36, <wei.liu2@citrix.com> wrote:
> On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote:
>> >>> On 08.03.16 at 17:20, <wei.liu2@citrix.com> wrote:
>> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
>> >> --- a/tools/libxl/xl_cmdimpl.c
>> >> +++ b/tools/libxl/xl_cmdimpl.c
>> >> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
>> >>      return 0;
>> >>  }
>> >>  
>> >> +static const struct {
>> >> +    int level;
>> >> +    char string[8];
>> >> +} loglvls[] = {
>> >> +    { 0, "none" },
>> >> +    { 1, "error" },
>> >> +    { 2, "warning" },
>> >> +    { 3, "info" },
>> >> +    { 4, "all" },
>> >> +    { 4, "debug" },
>> > 
>> > The semantics of the numbers should go into libxl_types.idl. Maybe
>> > something like
>> > 
>> > # Keep in sync with Xen log level.
>> > libxl_xen_log_level = Enumeration (...);
>> > 
>> > Then in here
>> > 
>> >     static const struct {
>> >         int level;
>> >         char string[8];
>> >     } loglvls[] = {
>> >         { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
>> >         { ..., "error" },
>> >         { ..., "warning" },
>> >         { ..., "info" },
>> >         { ..., "all" },
>> >         { ..., "debug" },
>> > 
>> > Please also note that after the introduction of this API, Xen log level
>> > will become part of the stable API and subject to some compatibility
>> > constraints. Is this what you wanted?
>> 
>> No, and I actually I'm having trouble following your request: This
>> lives in xl_cmdimpl.c, which I didn't think is subject to any stability
>> requirements in the mapping of strings (from the xl command line)
>> to numbers. It is _specifically_ that I do not want to fix those
>> mappings.
> 
> The new API libxl_log_level relies on the semantics of these mappings.
> To make the new API useful to all clients, the semantics of log levels
> needs to go into libxl_types.idl (as mentioned a few lines above), hence
> it becomes part of the stable API. Otherwise you end up with an API
> accepting arbitrary magic numbers.

Well - what do you suggest? I'm meanwhile willing to give up on this,
as baking the mapping into some ABI is clearly not what we should do
or what I want. Moving the translation into libxl also wouldn't help.
Which would leave the option of doing this in libxc, but then again I'm
generally opposed to passing around strings instead of numbers, as
the latter are better to work with at all layers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel