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

Re: [Xen-devel] [PATCH] [Xend] Move some backend configuration

  • To: John Levon <levon@xxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 02 Oct 2008 16:25:39 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 02 Oct 2008 08:26:08 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ackkox/iXrtjkJCWEd2OgAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] [Xend] Move some backend configuration

On 2/10/08 16:09, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

>> What happens if you try to write them, and fail? What are they actually used
>> for (e.g., communication with your own xvm tool stack?).
> They're both tool stack values, so in the sense that we can permanently
> patch xenstored, you don't need the change, you're right. Although, we're
> already
> carrying way way too much customizations.

Well, you don't need to patch xenstored. Your customised toolstack -- the
one that consumes these extra nodes -- can also open them up, right? The
only reason to open them in xend is if that is the difference between them
working and not working running against the default open-source toolstack.

I will allow these through if there is a net win for compatibility with the
default open-source toolstack. But I don't particularly want to do so just
to save you a one-line patch to your xend or equivalent.

> I don't see it going away, so in my mind explicitly saying now that you
> should only use guest/$(VENDOR) will avoid a lot of trouble down the
> line.

Mmm... I suppose I can see logic here. Vendor daemons running alongside
open-source xend for example.

 -- Keir

Xen-devel mailing list



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