From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMczX-0007VZ-6n for qemu-devel@nongnu.org; Sun, 09 Mar 2014 08:38:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMczS-0005nf-9C for qemu-devel@nongnu.org; Sun, 09 Mar 2014 08:38:07 -0400 Received: from mail-ob0-f179.google.com ([209.85.214.179]:62453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMczS-0005nb-4p for qemu-devel@nongnu.org; Sun, 09 Mar 2014 08:38:02 -0400 Received: by mail-ob0-f179.google.com with SMTP id va2so6032622obc.10 for ; Sun, 09 Mar 2014 05:38:01 -0700 (PDT) Date: Sun, 9 Mar 2014 12:37:09 +0000 From: Leandro Dorileo Message-ID: <20140309123709.GA18323@dorilex> References: <1394304438-14848-1-git-send-email-l@dorileo.org> <1394304438-14848-3-git-send-email-l@dorileo.org> <531C1894.8020804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531C1894.8020804@redhat.com> Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qemu-img: migrate to use qemu-arg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Peter Maydell , Fam Zheng , Stefan Weil , Michael Tokarev , qemu-devel@nongnu.org, Stefan Hajnoczi , Laszlo Ersek , Peter Lieven Hi Paolo, On Sun, Mar 09, 2014 at 08:30:28AM +0100, Paolo Bonzini wrote: > Il 08/03/2014 19:47, Leandro Dorileo ha scritto: > >Remove the arg parsing implementations using getopt and use qemu-arg. > >Also remove the qemu-img-cmds.hx since it's now generated on building time, > >adapted the build system to generate the .hx file using the qemu-img itself > >using the qemu-arg internal command generate-hx. > > > >Signed-off-by: Leandro Dorileo > > This makes it much harder to cross-compile QEMU. What's non-portable in this case? what would limit the QEMU cross-compile? > Also, I wonder how hard it > would be to apply the same approach to the main QEMU binary which already > uses QemuOpts for its more complex arguments; Yeah, you're right, QEMU binary is much more complex, In that case I think we should put QemuOpts and QemuArg together or so, I still need to better understand the current vl.c + QemuOpt source code to come up with a good solution. > for sure you risk that > accumulating multiple layers of abstractions makes the code even harder to > read than it is now. The idea is to keep things simple not the other way round. I think it's possible to accommodate both cases without imposing more complexity. Regards... -- Leandro Dorileo