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

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



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
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools


 


Rackspace

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