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-devel] [PATCH] fix error handler index in xm

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] fix error handler index in xm
From: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Date: Thu, 25 Aug 2005 10:56:20 +0100
Cc: "List: Xen Developers" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 25 Aug 2005 09:54:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m3ek8jmfg5.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <m3r7ckpfyp.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <3d8eece205082408487c9e6812@xxxxxxxxxxxxxx> <m3ek8jmfg5.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Wed, Aug 24, 2005 at 10:07:22AM -0700, Dan Smith wrote:
> CL> I've reverted this check-in because with the change applied, the
> CL> error messages are incorrect: 
> Ok, so the problem is rooted in the way the args list is manipulated
> in the subcommand handlers.  As it stands now (without the patch),
> some commands give a good error message, while others dump a stack
> trace if the domain doesn't exist:

Ah, ok.

> This is because destroy adds "bogus" into the args list at index 0,
> but domid does not.  I've attached a new patch that checks for this
> condition, and removes the "bogus" entry from the list if the
> subcommand added it.  This makes the call to handle_xend_error() work
> in both situations:
>   # xm destroy foo
>   Error: Domain 'foo' not found when running 'xm destroy'
>   # xm domid foo
>   Error: Domain 'foo' not found when running 'xm domid'
> Is that an acceptable solution for now?  Perhaps a cleanup of the
> inconsistent subcommand handler behavior is in order.  I can do that
> when I start work on the remaining interface changes.

Yes, I've checked this in for now, but making the subcommand handler
behavious consistent would be good.


Xen-devel mailing list

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