From mboxrd@z Thu Jan  1 00:00:00 1970
From: Blue Swirl <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
Date: Mon, 11 Apr 2011 20:15:14 +0300
Message-ID: <BANLkTimsnTNVDHMpbbFTrKFXgfxSf+vRtQ@mail.gmail.com>
References: <4D9CAAF9.7000509@codemonkey.ws> <20110406150818.56707b9b@doriath>
 <4D9CAE4B.7080305@siemens.com> <20110406160020.373cb5a2@doriath>
 <BANLkTinUfnq6b2u_bfdB_zc3z8dg=4gAbA@mail.gmail.com> <4D9CC044.2000705@codemonkey.ws>
 <BANLkTim4iP_YRjOCYH986BB=ec-dwcjfQA@mail.gmail.com> <4D9E0352.2050204@codemonkey.ws>
 <20110407185108.GE7100@redhat.com> <BANLkTi=Kn7gArGY9ZVqY465_bgumMZhEfg@mail.gmail.com>
 <20110407191759.GG7100@redhat.com> <4D9E2F6F.3040008@codemonkey.ws>
 <4DA16FCB.7040509@redhat.com> <m34o65w9sp.fsf@blackfin.pond.sub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cc: Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Peter Maydell <peter.maydell@linaro.org>,
	Lai Jiangshan <eag0628@gmail.com>,
	Jiangshan <laijs@cn.fujitsu.com>, Gleb Natapov <gleb@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Luiz Capitulino <lcapitulino@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-vx0-f174.google.com ([209.85.220.174]:57883 "EHLO
	mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753865Ab1DKRPf (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 11 Apr 2011 13:15:35 -0400
Received: by vxi39 with SMTP id 39so4324863vxi.19
        for <kvm@vger.kernel.org>; Mon, 11 Apr 2011 10:15:34 -0700 (PDT)
In-Reply-To: <m34o65w9sp.fsf@blackfin.pond.sub.org>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Avi Kivity <avi@redhat.com> writes:
>
>> On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>>>
>>> And it's a good thing to have, but exposing this as the only API to
>>> do something as simple as generating a guest crash dump is not the
>>> friendliest thing in the world to do to users.
>>
>> nmi is a fine name for something that corresponds to a real-life nmi
>> button (often labeled "NMI").
>
> Agree.

We could also introduce an alias mechanism for user friendly names, so
nmi could be used in addition of full path. Aliases could be useful
for device paths as well.