Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Joao Martins <joao.m.martins@xxxxxxxxxx>]

On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +0000, Joao Martins wrote:
>>>> * Toolstack constructs a key value store of features, and user specifies 
>>>> those
>>>> through special entry names prefixed also as "require". Toolstack is 
>>>> stateless thus sys
>>>> admin has full control over what to pass to the backend. In other words it
>>>> doesn't look at particular feature names/values.
>>>>
>>>> * The backend will then use that for seeding its maximum feature set to the
>>>> frontend.
>>>
>>> Oh, I see. So the backend picks up the suggested config from this
>>> directory together with it's capabilities and then produces the final
>>> set of features exposed to the frontend.
>>>
>>> In order to prevent adding more logic to the backends, would it make
>>> sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
>>> and do those calculations from the toolstack itself, so that the
>>> toolstack directly writes the features to the backend top level
>>> xenstore directory?
>>
>> So you want the toolstack to read the /sys/ entries? How would that work
>> for driver domains?
> 
> Right, that won't work for driver domains... And feeding that
> information from a driver domain into the control domain is even
> worse, so I'm fine with this.

Right, in the first email thread[0] we had, Konrad also pointed this out about
FreeBSD and driver domains. So the choice of xenstore over OS specific
constructs are because of driver domains basically.

Joao

[0] https://lists.xen.org/archives/html/xen-devel/2017-09/msg02275.html

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