On 18/09/18 13:20, Jan Beulich wrote: >>>> On 18.09.18 at 13:10, <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). >> >> So lets look what would be needed for adding something like the >> per-domain xpti parameter using binary interfaces: >> >> 1 an extension of some domctl interface, maybe bumping of the domctl >> interface version >> 2 adding the logic to domctl handling >> 3 adding libxc support >> 4 adding libxl support >> 5 adding a new xl sub-command >> 6 adding domain config support >> 7 adding documentation >> >> With my approach only 2 (in a modified form, parameter handling instead >> of domctl, but comparable in the needed effort) and 7 are needed. >> >> So once the framework is in place it is _much_ easier to add new >> features. > > All the above would hold if the individual options were expressed as > e.g. flags in an extensible bit vector.
Who would translate the new option into a bit vector? This would be the tools (libxc/libxl/xl), so those need to be modified for each new bit. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
