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

[Xen-devel] semantics of GETDOMAININFO


  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Kip Macy <kip.macy@xxxxxxxxx>
  • Date: Sun, 8 May 2005 14:39:39 -0700
  • Delivery-date: Sun, 08 May 2005 21:39:14 +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:mime-version:content-type:content-transfer-encoding:content-disposition; b=TIpJQjX62/d01hmSNIp1JxTY3icaifcZcYqhWuM/8qJc8IAwLIz5RVvQza3B4ISK4pq9m1mGqsmRoy9KbXnE/rEpWPF3vyGJ2RXTxMnKnni+pLghrhmNW8l1UsORV1UfUEJLVdYyz3hkYmOdBAqid9pNACfwVBp56UoHN1j68lM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

One of the things that I've always thought was weird, but didn't pay
too close attention to is the fact that GETDOMAININFO will return a
valid result even if we give it a domid that is no longer valid.
Looking at the code we get back the first valid domain after the domid
we pass in.

What is the reason for this design choice? When I request the
attributes of a process I don't get the attributes for the next pid up
with a pid field set to the process id of the process I actually got
the attributes for.

       -Kip

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


 


Rackspace

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