From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:56229)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Qm8xo-0006ZS-6C
	for qemu-devel@nongnu.org; Wed, 27 Jul 2011 14:36:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1Qm8xm-0001Ec-RO
	for qemu-devel@nongnu.org; Wed, 27 Jul 2011 14:36:12 -0400
Received: from verein.lst.de ([213.95.11.211]:46686 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Qm8xm-0001EP-I2
	for qemu-devel@nongnu.org; Wed, 27 Jul 2011 14:36:10 -0400
Date: Wed, 27 Jul 2011 20:36:10 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20110727183610.GC14736@lst.de>
References: <20110727152457.GK18528@redhat.com>
	<4E303E24.3050800@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E303E24.3050800@codemonkey.ws>
Subject: Re: [Qemu-devel] RFC: moving fsfreeze support from the
	userland	guest agent to the guest kernel
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Andrea Arcangeli <aarcange@redhat.com>, Jes Sorensen <Jes.Sorensen@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, Michael Roth <mdroth@linux.vnet.ibm.com>, qemu-devel@nongnu.org

Initiating the freeze from kernelspace doesn't make much sense.  With
virtio we could add in-band freeze request to the protocol, and although
that would be a major change in that way virtio-blk works right now it's
at least doable.  But all other "real" storage targets only communicate
with their initators over out of band procotols that are entirely handled
in userspace, and given their high-level nature better are - that is if
we know them at all given how vendors like to keep this secrete IP
closed and just offer userspace management tools in binary form.

building new infrastructure in the kernel just for virtio, while needing
to duplicate the same thing in userspace for all real storage seems like
a really bad idea.  That is in addition to the userspace freeze notifier
similar to what e.g. Windows has - if the freeze process is driven from
userspace it's much easier to handle those properly compared to requiring
kernel upcalls.