On 18/09/18 13:20, George Dunlap wrote: > On 09/18/2018 12:19 PM, Jan Beulich wrote: >>>>> On 18.09.18 at 13:02, <jgr...@suse.com> wrote: >>> On 18/09/18 12:32, Jan Beulich wrote: >>>>>>> On 18.09.18 at 08:02, <jgr...@suse.com> wrote: >>>>> Instead of using binary hypervisor interfaces for new parameters of >>>>> domains or cpupools this patch series adds support for generic text >>>>> based parameter parsing. >>>>> >>>>> Parameters are defined via new macros similar to those of boot >>>>> parameters. Parsing of parameter strings is done via the already >>>>> existing boot parameter parsing function which is extended a little >>>>> bit. >>>>> >>>>> Parameter settings can either be specified in configuration files of >>>>> domains or cpupools, or they can be set via new xl sub-commands. >>>> >>>> Without having looked at any of the patches yet (not even their >>>> descriptions) I'm still wondering what the benefit of textual parameters >>>> really is: Just like "binary" ones, they become part of the public >>>> interface, and hence subsequently can't be changed any more or >>>> less than the ones we currently have (in particular, anything valid in >>>> a guest config file will imo need to remain to be valid and meaningful >>>> down the road). >>>> >>>> If this is solely or mainly about deferring the parsing from the tool >>>> stack to the hypervisor, then I'm not at all convinced of the approach >>>> (I'd even be tempted to call it backwards). >>> >>> The main advantage is that it would be much easier to backport new >>> parameters like the xpti per-domain one. No need to bump sysctl/domctl >>> interface versions for that. >> >> Additions to sysctl/domctl interfaces don't require such a bump. >> >>> It might be a good idea to support mandatory and optional parameters >>> in the guest config. Optional parameters not supported by the hypervisor >>> would then be ignored instead of leading to failure at guest creation >>> time. >> >> Except that over time opinions may change what is supposed to >> be optional vs mandatory. > > I thought the idea would be that the admin would specify which ones were > optional or mandatory.
Right. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
