From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48985)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jsnow@redhat.com>) id 1aBPgg-0006rA-NJ
	for qemu-devel@nongnu.org; Tue, 22 Dec 2015 11:21:23 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jsnow@redhat.com>) id 1aBPgf-0007nS-M4
	for qemu-devel@nongnu.org; Tue, 22 Dec 2015 11:21:22 -0500
References: <567206C0.6010403@redhat.com>
	<w51si2v20yh.fsf@maestria.local.igalia.com>
	<567855AA.8090606@redhat.com>
	<w51vb7qbgm8.fsf@maestria.local.igalia.com>
From: John Snow <jsnow@redhat.com>
Message-ID: <5679787B.7050607@redhat.com>
Date: Tue, 22 Dec 2015 11:21:15 -0500
MIME-Version: 1.0
In-Reply-To: <w51vb7qbgm8.fsf@maestria.local.igalia.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-block] Jobs 2.0 QAPI [RFC]
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: Alberto Garcia <berto@igalia.com>, Qemu-block <qemu-block@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>



On 12/22/2015 11:19 AM, Alberto Garcia wrote:
> On Mon 21 Dec 2015 08:40:26 PM CET, John Snow <jsnow@redhat.com> wrote:
>> However, better flexibility also plays a part. Say we have two devices:
>>
>> [drive0]: [X] --> [Y] --> [Z]
>> [drive1]: [A] --> [B]
>>
>> In theory, we should be able to commit Z into Y into X while we
>> simultaneously perform a backup from X to A. We definitely can't do that
>> now.
>>
>> There may be some better use cases -- backups, fleecing and other
>> read-only operations in particular have a high likelihood of being able
>> to run concurrently with other operations.
>>
>>
>> We definitely *can* just extend the old API to allow for these kinds of
>> things, but since it represents a new paradigm of job manipulation, it's
>> easier to just extend the block jobs api into a new "jobs" API and allow
>> the system to expand to other subsystems.
> 
> That sounds good to me. Since I'm trying to achieve something similar
> with the block-stream operations (two or more ops in parallel) I'll try
> to follow this new API closely.
> 
> Thanks,
> 
> Berto
> 

Sure! Make sure you check out Jeff Cody's RFC on the new permissions
system which will form the basis for allowing multiple jobs, too.

--js