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


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

To: Dan Smith <danms@xxxxxxxxxx>
Subject: [Xen-devel] Re: [Xen-tools] [PATCH] Clean up dom_get() usage
From: Christian Limpach <christian.limpach@xxxxxxxxx>
Date: Fri, 16 Sep 2005 23:03:59 +0100
Cc: Xen Tools Developers <xen-tools@xxxxxxxxxxxxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Sep 2005 22:01:46 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ejoqTs5gfEW9ZuGG3LT14YCwQ57ol5OkoUrseUeCRuivLSGkUek4/RIet1aeytEy0zwR3t//nHl/+sdEWPcN0gF6OCVg2nToqwchTSNhpltmkpx7oX1EfCKxzaB7n8qSsrUyBmDD9T1ErqJEFrqCClcK2TomHhRomBHKV7f2coc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <874q8kivdm.fsf@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87irx2xnf3.fsf@xxxxxxxxxx> <3d8eece20509161222782a9051@xxxxxxxxxxxxxx> <874q8kivdm.fsf@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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...


Xen-devel mailing list

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