Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross <jgross@xxxxxxxx>]

On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
> configurable"):
>> So you are telling me the xenstore domain won't work for this case?
> 
> Yes.

That's rather unfortunate. So in order to be able to make xenstore
domain a common setup we need to find a solution for support of
xs_restrict() via xenbus, right?

TBH, the way xs_restrict() was introduced is rather weird. It is
completely bound to the socket interface of oxenstored. So anyone
wanting to use xs_restrict() is limited to oxenstored running in
dom0. No way to use xenstored or a xenstore domain. I'm really
disappointed such a design was accepted and is now the reason for
not being able to disaggregate dom0.

I've searched through the xen-devel archives and found a very
interesting mail:

http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html

The "restrict" feature was added without any further discussion how
it is implemented and that the C-variant doesn't support it. The
explicit question about non-existing features in the C xenstored was
answered just with "the xenstore wire protocol doesn't change".

With:

http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html

the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
was added. Again no mentioning of the special implementation in
oxenstored.

Really, this is not how open source development should be done!
Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
support as it has been introduced in a foul way.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel