[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: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: > >> This is pretty simplistic for now, but I'd rather have someone better > >> friends with the tools improve it (if desired). > >> > >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > >> > >> --- 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; > >> + GC_INIT(ctx); > >> + if (set) { > >> + ret = xc_set_log_level(ctx->xch, guest, *lower_thresh, > >> *upper_thresh); > >> + } else { > >> + ret = xc_get_log_level(ctx->xch, guest, lower_thresh, > >> upper_thresh); > >> + } > >> + if ( ret < 0 ) { > >> + LOGE(ERROR, "%s %slog level", > >> + set ? "setting" : "getting", guest ? "guest " : ""); > >> + GC_FREE; > >> + return ERROR_FAIL; > >> + } > >> + GC_FREE; > >> + return 0; > >> +} > >> + > > > > As Dario said, libxl tends to have getter and setter pair. > > "Tends to have" still leaves room for me to get away without > adjustments. Could you please clearly state whether splitting > this is required for acceptance? > Yes, please make a pair of getter and setter. > >> --- 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. Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |