From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws9Ps-0001mu-1t for qemu-devel@nongnu.org; Wed, 04 Jun 2014 07:31:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ws9Pj-0001lz-LM for qemu-devel@nongnu.org; Wed, 04 Jun 2014 07:31:35 -0400 Received: from averel.grnet-hq.admin.grnet.gr ([195.251.29.3]:4471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws9Pj-0001lg-Dz for qemu-devel@nongnu.org; Wed, 04 Jun 2014 07:31:27 -0400 Message-ID: <538F036D.2060704@grnet.gr> Date: Wed, 04 Jun 2014 14:30:53 +0300 From: Chrysostomos Nanakos MIME-Version: 1.0 References: <1401718539-11304-1-git-send-email-cnanakos@grnet.gr> <1401718539-11304-2-git-send-email-cnanakos@grnet.gr> <538C8A7D.1020402@redhat.com> <538C929B.6000304@grnet.gr> <20140602153126.GF4045@noname.str.redhat.com> In-Reply-To: <20140602153126.GF4045@noname.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/1] block: Support Archipelago as a QEMU block backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , qemu-devel@nongnu.org, stefanha@redhat.com Hi, On 06/02/2014 06:31 PM, Kevin Wolf wrote: > Am 02.06.2014 um 17:04 hat Chrysostomos Nanakos geschrieben: >> Hi, >> >> On 06/02/2014 05:30 PM, Eric Blake wrote: >>> On 06/02/2014 08:15 AM, Chrysostomos Nanakos wrote: >>>> VM Image on Archipelago volume is specified like this: >>>> >>>> file=archipelago:[/mport=[:vport=]] >>>> or >>> I still think that there is no need to burden the code with this >>> shorthand... >> If everyone agrees I can totally remove that part. > I don't think it's a bad idea to provide a shortcut for human users. The > important point is just that internally it's not the main interface, but > mapped to the structured option (which I think your patch achieves now). > >>>> file.driver=archipelago,file.volume=[,file.mport=[, >>>> file.vport=]] >>> ...when this version is easier to support. Older protocols have file= >>> abuse due to back-compat reasons, but new protocols should not start out >>> with baggage. >>> >>> >>>> --- >>>> MAINTAINERS | 5 + >>>> block/Makefile.objs | 1 + >>>> block/archipelago.c | 1174 +++++++++++++++++++++++++++++++++++++++++++++++++++ >>> This is a lot to review at once - is there any reasonable way to break >>> it into a series of smaller patches? >> It will be really difficult to break it in smaller patches, and I >> believe it will more difficult for someone to review it. > Not sure how much easier the review would become, but the obvious split > that works almost always is to do a read-only driver in patch 1, and > then add write and create support in patches 2 and 3. I've just send v3 patch series which consists of three parts. The first one implements the read/write functionality, it seemed difficult to break it down to two patches, one for read and the other for write. I hope this is better than before and not very difficult to review it. The second part implements the .bdrv_create() function and adds support for creating Archipelago images. The third and last part adds QMP support by introducing a new enum, BlockdevOptionsArchipelago. Regards, Chrysostomos.