From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [Xend] Move some backend configuration Date: Thu, 02 Oct 2008 16:25:39 +0100 Message-ID: References: <20081002150929.GC1088@totally.trollied.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20081002150929.GC1088@totally.trollied.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 2/10/08 16:09, "John Levon" 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