From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55390 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OQcEM-0007qL-Ud
	for qemu-devel@nongnu.org; Mon, 21 Jun 2010 04:19:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OQcEL-00089G-N0
	for qemu-devel@nongnu.org; Mon, 21 Jun 2010 04:19:46 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40131)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OQcEL-000890-FK
	for qemu-devel@nongnu.org; Mon, 21 Jun 2010 04:19:45 -0400
Message-ID: <4C1F2093.3060807@redhat.com>
Date: Mon, 21 Jun 2010 10:19:31 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <m3ocf8ts1y.fsf@blackfin.pond.sub.org>
	<4C1DF2C1.5040505@redhat.com>
In-Reply-To: <4C1DF2C1.5040505@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack
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: Avi Kivity <avi@redhat.com>
Cc: Christoph Hellwig <chellwig@redhat.com>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>

Am 20.06.2010 12:51, schrieb Avi Kivity:
> On 06/18/2010 03:59 PM, Markus Armbruster wrote:
>> The code is pretty confused about format vs. protocol, and so are we.
>> Let's try to figure them out.
>>
>>  From cruising altitude, all this format, protocol, stacking business
>> doesn't matter.  We provide a bunch of arguments, and get an image.
>>
>> If you look more closely, providing that image involves sub-tasks.  One
>> is to haul bits.  Another one is to translate between bits in different
>> formats.
>>
>> Working hypothesis:
>>
>> * A protocol hauls image bits.  Examples: file, host_device, nbd.
>>
>> * A format translates image formats.  Examples: raw, qcow2.
>>
>>    
> 
> Is there a reason to make the distinction?  Is there a reason to expose 
> the distinction to the user?

There are good reasons to make that distinction internally. There's no
need to expose it to the user - the question is if it helps or not.

Historically, format and protocol are defined like this (so in fact they
are user-visible currently):

* A format is what you specify as file=...
* A protocol is what is encoded in the file name

And I think as long as you have exactly one format and one protocol,
it's easier to understand than a chain of block drivers. But that's
really just about how to expose it.

Kevin