From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQzjj-0005qy-4k for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQzjZ-0003qJ-Kq for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:07:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQzjZ-0003qD-Ce for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:06:53 -0400 From: Markus Armbruster References: <1351011870-1680-1-git-send-email-peter.maydell@linaro.org> <87d3088dm8.fsf@blackfin.pond.sub.org> Date: Wed, 24 Oct 2012 14:06:49 +0200 In-Reply-To: (Peter Maydell's message of "Wed, 24 Oct 2012 10:21:50 +0100") Message-ID: <87objs3wh2.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 0/7] ARM boards: don't prematurely explode QEMUMachineInitArgs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Anthony Liguori , Eduardo Habkost , patches@linaro.org, qemu-devel@nongnu.org, Blue Swirl , Max Filippov Peter Maydell writes: > On 24 October 2012 09:42, Markus Armbruster wrote: >> Peter Maydell writes: >> >>> A lot of the ARM board models follow the pattern of having a >>> single common init function which is called with various >>> parameters from the QEMUMachine init function for several board >>> model variants. The change to QEMUMachineInitArgs in commit 5f072e >>> took the fairly mechanical approach of splitting the QEMUMachineInitArgs >>> fields out in each variant's init function to pass to an unchanged >>> common init function. This is a bit repetitive, so clean them up >>> to just pass the QEMUMachineInitArgs directly to the common >>> function instead. >> >> A quick grep finds similar cleanup opportunities in >> >> hw/exynos4_boards.c exynos4_boards_init_common() >> hw/pc_piix.c pc_init1() >> hw/sun4m.c sun4m_hw_init() >> hw/sun4u.c sun4uv_init() >> hw/xtensa_lx60.c lx_init() >> hw/xtensa_sim.c sim_init() > > I deliberately stuck to the ARM boards on the basis that the > others were a little out of my jurisdiction. I missed the > exynos4 though. Fair enough. Cc'ing some relevant maintainers.