From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55290 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OovdA-0004mM-4g
	for qemu-devel@nongnu.org; Fri, 27 Aug 2010 05:53:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1Oovd5-0007X4-0C
	for qemu-devel@nongnu.org; Fri, 27 Aug 2010 05:53:51 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60095)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1Oovd4-0007Wv-O4
	for qemu-devel@nongnu.org; Fri, 27 Aug 2010 05:53:46 -0400
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/5] Add generic drive hotplugging
References: <1282600951-30803-1-git-send-email-agraf@suse.de>
	<1282600951-30803-5-git-send-email-agraf@suse.de>
Date: Fri, 27 Aug 2010 11:53:31 +0200
In-Reply-To: <1282600951-30803-5-git-send-email-agraf@suse.de> (Alexander
	Graf's message of "Tue, 24 Aug 2010 00:02:30 +0200")
Message-ID: <m3aao8pejo.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Luiz Capitulino <lcapitulino@redhat.com>, qemu-devel List <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>, Gerd Hoffmann <kraxel@redhat.com>

Alexander Graf <agraf@suse.de> writes:

> The monitor command for hotplugging is in i386 specific code. This is just
> plain wrong, as S390 just learned how to do hotplugging too and needs to
> get drives for that.
>
> So let's add a generic copy to generic code that handles drive_add in a
> way that doesn't have pci dependencies.
>
> I'm not fully happy with the patch as is. IMHO there should only be a
> single target agnostic drive_hot_add function available. How we could
> potentially fit IF_SCSI in there I don't know though.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>

Yes, we need a target-agnostic command to add host block devices.  All
we have now is x86's drive_add, which isn't target-agnostic, because its
normal function is to add both host and guest part, and the latter is
entangled with PCI.

Your patch creates a copy of x86's drive_add with the guest bits
stripped from the code, so it's usable for non-PCI targets.  Guest bits
remain in the syntax (first argument, useless baggage with your
command).  Ugly.

I'm working on a clean solution for this problem.  If you must have a
solution right away, and ugly is fine, then your patch should do for
now.

In my opinion, pci_add, pci_del and drive_add all need to go.  They're
insufficiently general, and they fail to separate host and guest parts.