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

[Christian Limpach <christian.limpach@xxxxxxxxx>]

On 9/16/05, Dan Smith <danms@xxxxxxxxxx> wrote:
> 
> 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?

How could we not get the current domain's info?

> 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.

Actually, the code has also changed a bit with the patch I applied
earlier.  We quite exlicitly now operate on domain with ID 0.

> 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.

Indeed, I've found that most of the strangeness is caused by random
code mucking about with random information all over the place -- I
don't think we should add any more of that...

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel