Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.09.18 at 13:26, <jgross@xxxxxxxx> wrote:
> On 18/09/18 13:19, Jan Beulich wrote:
>>>>> On 18.09.18 at 13:02, <jgross@xxxxxxxx> wrote:
>>> On 18/09/18 12:32, Jan Beulich wrote:
>>>>>>> On 18.09.18 at 08:02, <jgross@xxxxxxxx> 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.
> 
> What are XEN_DOMCTL_INTERFACE_VERSION and XEN_SYSCTL_INTERFACE_VERSION
> for then?

To guard _existing_ users of _existing_ interfaces.

>>> 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.
> 
> And that would change how in case of binary interfaces?

Optional vs mandatory is an orthogonal discussion.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel