[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.