On 09/18/2018 12:32 PM, Juergen Gross wrote:
> 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.
A bit vector would only allow on/off; it wouldn't allow you to set
numeric parameters, for example.
I like the idea of being able to add configuration parameters without
having a huge amount of boilerplate; and also of being able to backport
parameters like xpti without having to worry so much about compatibility.
But I'm not a fan of the idea of using a "string blob" to accomplish
that. It's convenient for the exact use case you seem to be
contemplating: having a user add the string into the xl config file, and
having nobody but the hypervisor interpret it. But what about tools
that may want to set that parameter? Or tools that want to query the
parameter, or "introspect" on the domain settings or whatever? Now they
have to have a bunch of code to generate and parse the string code.
Could we have a reasonably generic structure / union, with a parameter
number, that we could pass in instead? Something like:
struct domain_parameter {
int param_num;
int val;
}
And then have a list somewhere of string values -> parameter numbers
that callers could use to translate strings into values?
That way the above list would look like:
1. Add new parameter in Xen
2. Add a string name -> parameter number in a header somewhere
3. Add a libxl #define with that parameter number
You'd have to recompile xl against the new header, but you were probably
going to do that anyway.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
