All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Doug Goldstein <cardoe@cardoe.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: making xenstore domain easy configurable
Date: Tue, 28 Jun 2016 15:52:21 +0200	[thread overview]
Message-ID: <57728115.5080000@suse.com> (raw)
In-Reply-To: <8f3f6450-52c0-b553-affd-7d639339d5d7@citrix.com>

On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> 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.
> 
> I don't think the lack of xs_restrict() working over the ring should
> preclude these improvements to the configuration of how xenstored starts up.
> 
> Ideally, this issue would be listed in an appropriate place in
> docs/features/, in the hope that it gets considered and addressed in the
> future.

Digging a little bit deeper I think the current xs_restrict()
implementation renders an oxenstore domain completely useless: as
soon as dom0 tries to use xs_restrict() it will loose its privileges
as the complete dom0 connection will be affected. :-(


Juergen

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

  parent reply	other threads:[~2016-06-28 13:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27 12:43 making xenstore domain easy configurable Juergen Gross
2016-06-27 12:59 ` Andrew Cooper
2016-06-27 13:06   ` Juergen Gross
2016-06-27 20:59   ` Doug Goldstein
2016-06-28 10:32     ` Juergen Gross
2016-06-28 10:39     ` David Vrabel
2016-06-28 10:45       ` Ian Jackson
2016-06-28 10:50         ` Juergen Gross
2016-06-28 11:03           ` Ian Jackson
2016-06-28 11:56             ` Juergen Gross
2016-06-28 12:42               ` Andrew Cooper
2016-06-28 13:36                 ` Juergen Gross
2016-06-28 13:59                   ` Andrew Cooper
2016-06-28 14:58                     ` Juergen Gross
2016-06-28 15:10                       ` Andrew Cooper
2016-06-28 15:17                     ` Doug Goldstein
2016-06-28 15:23                       ` Andrew Cooper
2016-06-28 15:27                         ` Juergen Gross
2016-06-28 16:27                     ` Jan Beulich
2016-06-28 16:34                       ` Doug Goldstein
2016-06-28 13:52                 ` Juergen Gross [this message]
2016-06-28 13:54                   ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57728115.5080000@suse.com \
    --to=jgross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.