This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-tools] [PATCH] Clean up dom_get() usage

To: Christian.Limpach@xxxxxxxxxxxx
Subject: Re: [Xen-tools] [PATCH] Clean up dom_get() usage
From: Dan Smith <danms@xxxxxxxxxx>
Date: Fri, 16 Sep 2005 13:57:09 -0700
Cc: Xen Tools Developers <xen-tools@xxxxxxxxxxxxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Sep 2005 20:56:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <87irx2xnf3.fsf@xxxxxxxxxx> <3d8eece20509161222782a9051@xxxxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)
CL> I don't think the 3rd hunk is needed.

The temporary variable is a added so that we can verify that dom_get()
returned non-None.  A failure to get the current domain's info from xc
(which could happen) would result in an "unsubscriptable object"
exception in a less-than-obvious place while xend is starting up.

Am I missing something?

CL> It would make more sense to have a patch which replaces the magic
CL> dom0 domid by a global variable indicating the domid of the domain
CL> where xend is running.

The domid in this case isn't magic though, is it?  We just use the
domid that is passed to us, which I think we assume is correctly set
to the privileged domain's ID.

Although the temporary variable is definitely not indicative of this
fact :)

CL> It's possibly a sensible behaviour, but I'd like to move away from
CL> code which does stuff as a side effect.  We don't want to end up
CL> with countless places doing random actions just because they
CL> happen to notice a state change first.

I see your point.  However, I do feel that we should be informative
and defensive where possible.  I think that no matter where it is
detected, the hypervisor reporting a domain is no longer present
should not be ignored.  Very recently, there have been very strange
problems occurring due to stale state that gets left around.

Would it be appropriate to take an action based on what state we think
we're in?  For example, if we were running, mark ourselves as
"crashed"; if we were shutting down, remove ourselves from the list.

Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx

Xen-tools mailing list

<Prev in Thread] Current Thread [Next in Thread>