From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33263)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RpMop-00028y-OP
	for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:32:32 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RpMoi-0002Km-Gk
	for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:32:31 -0500
Received: from mail-vw0-f45.google.com ([209.85.212.45]:50520)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RpMoi-0002Kh-EI
	for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:32:24 -0500
Received: by vbjk17 with SMTP id k17so2138264vbj.4
	for <qemu-devel@nongnu.org>; Mon, 23 Jan 2012 08:32:23 -0800 (PST)
Sender: Grant Likely <glikely@secretlab.ca>
Date: Mon, 23 Jan 2012 09:32:25 -0700
From: Grant Likely <grant.likely@secretlab.ca>
Message-ID: <20120123163225.GA25944@ponder.secretlab.ca>
References: <1326213943-878-1-git-send-email-mark.langsdorf@calxeda.com>
	<1327008660-16789-1-git-send-email-mark.langsdorf@calxeda.com>
	<1327008660-16789-5-git-send-email-mark.langsdorf@calxeda.com>
	<CAFEAcA8U_Fr+gpJEw3H2=2HfUWa8qv_Prsk3XSXL2QiYRCHG+w@mail.gmail.com>
	<4F18A475.80009@calxeda.com>
	<CAFEAcA_McczeXEeGrS4NEp+a7iuxEeRJ1Ukq+pr6v_7sh5NLKA@mail.gmail.com>
	<4F197099.2020708@calxeda.com>
	<CAFEAcA9eV9PjyCFhH2CQ5D3Zx7kgj1qXm5gLFb_=pM6LVF61OQ@mail.gmail.com>
	<20120120182725.GV4223@ponder.secretlab.ca>
	<CAFEAcA8Yce7=awDLdX6-sMKvHFeN1939KS9MsUHQN+toA=W6Hg@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAFEAcA8Yce7=awDLdX6-sMKvHFeN1939KS9MsUHQN+toA=W6Hg@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Qemu-devel] Adding -dtb option to qemu
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: Peter Maydell <peter.maydell@linaro.org>
Cc: edgar.iglesias@gmail.com, qemu-devel@nongnu.org, Rob Herring <rob.herring@calxeda.com>

Hey Peter,

I need some advice.  I'm adding a -dtb option to qemu for specifying a
dtb filename to be passed on to the kernel, similar to how the -initrd
flag works.  The dtb filename needs to then be passed on to the
selected machine, and it looks like the machine->init() callback is
the best way to do that.

However, the current init callback prototype looks like this:

typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
				 const char *boot_device,
				 const char *kernel_filename,
				 const char *kernel_cmdline,
				 const char *initrd_filename,
				 const char *cpu_model);

Now, I could simply add an new "dtb_filename" to the argument list and
fix up all of the users (looks to be about 90 machines), but that
seems like a lot of churn that will need to be repeated the next time
a new argument needs to be passed to the init func.

Alternately, I could do something like this:

struct machine_args {
	ram_addr_t ram_size;
	const char *boot_device;
	const char *kernel_filename,
	const char *kernel_cmdline,
	const char *initrd_filename,
	const char *dtb_filename,
	const char *cpu_model,
};

typedef void QEMUMachineInitFunc(const struct machine_args *args);

And then I'd fix up all the users, which would be about the same
amount of churn, but subsequent additions would be a lot easier.

A third option would be to add a new ".dt_init()" that is executed
instead of .init() if populated, but that seems like an ugly band-aid
to me.

How should I approach this?  Or is there a better way to pass data to
so that it is available at machine->init() time?

g.