[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command
On Mon, Mar 14, 2016 at 09:49:11AM -0600, Jan Beulich wrote: > >>> On 14.03.16 at 16:36, <wei.liu2@xxxxxxxxxx> wrote: > > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote: > >> >>> On 08.03.16 at 17:20, <wei.liu2@xxxxxxxxxx> 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. > I don't have a very clear idea on what to suggest at the moment, sorry. What kind of changes to xen log level might happen in the future? Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |