From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:40532)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RztJy-0005TH-Oq
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 12:16:11 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RztJs-0005WT-PE
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 12:16:10 -0500
Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:33636)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RztJs-0005Vv-JP
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 12:16:04 -0500
Received: by lahi5 with SMTP id i5so8545011lah.4
	for <qemu-devel@nongnu.org>; Tue, 21 Feb 2012 09:16:01 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <4F4397D1.2020807@redhat.com>
References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com>
	<4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com>
	<e2d5747f27ca519ddc6b7f0133e0a1a8@mail.gmail.com>
	<4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com>
	<4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com>
	<4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com>
	<4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com>
	<4F32489A.80307@redhat.com> <4F32788C.60904@zerto.com>
	<CAJSP0QXRdU4XhW2wU+vOPh+vuzEECdKEWUGzaaENEtTbpRfKMg@mail.gmail.com>
	<4F40FBD6.2000500@zerto.com> <4F425987.20103@redhat.com>
	<4F435DD2.8080600@redhat.com> <4F4360C7.5080806@redhat.com>
	<4F4368BF.4040707@redhat.com> <4F436D76.6090206@redhat.com>
	<4F43773B.6060109@redhat.com> <4F4381CE.70604@redhat.com>
	<4F4397D1.2020807@redhat.com>
Date: Tue, 21 Feb 2012 17:16:01 +0000
Message-ID: <CAJSP0QURdM_YFT1_gbCJRgHv2KMv7F3UBfvhhfaD6tZv2BbNiw@mail.gmail.com>
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= <tomer@zertodata.com>, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= <oded@zerto.com>, Jeff Cody <jcody@redhat.com>, dlaor@redhat.com, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Zhi Yong Wu <zwu.kernel@gmail.com>, Federico Simoncelli <fsimonce@redhat.com>, Ori Mamluk <omamluk@zerto.com>, Yair Kuszpet <yairk@zerto.com>, Paolo Bonzini <pbonzini@redhat.com>

On Tue, Feb 21, 2012 at 1:10 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 21.02.2012 12:36, schrieb Paolo Bonzini:
> Oh, and just to open another can of worms: We should probably design in
> the notion of media (which can be ejected etc.) and drives (which always
> stay there). We don't have a clean separation today.

Media and drives are guest state, they should be part of device
emulation and not host device implementation.

The layering issue is that things like floppy and CD-ROM passthrough
do deal with media change and status.

Does it make sense to have a hw/drive.c for the guest state associated
with a -drive?

Stefan