On Tue, Feb 21, 2012 at 5:56 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 20 February 2012 19:51, Andreas Färber <afaer...@suse.de> wrote: >> Am 20.02.2012 20:43, schrieb Peter Maydell: >>> I don't particularly care how we QOMify arm_boot (it's not exactly at >>> the top of my priority list demanding attention), I do care that (a) >>> we have a sensible user-facing interface [ie command line options] and >>> (b) vl.c can usefully just pass the information from those options >>> straight to the boot loader code.
So when I trialled this patch I used the -device argument to instantiate the bootloader on the command line: qemu-system-arm -M versatilepb --device arm_linux_loader,kernel_filename=kernel.foo,initrd=image.bar... With this approach I was able to add command line args (if you will) to arm_boot without touching vl.c, qemu_opts or any of the arm machine models. With changing only arm_boot.c you would get your dtb argument: qemu-system-arm -M versatilepb --device arm_linux_loader,kernel_filename=kernel.foo,initrd=image.bar,-dtb=blah.dtb Paul and Andreas reached the conclusion (correct me if I have misunderstood) that the machine model should have still have to explictly instantiate the bootloader "device" (whether that be a QOM device or arm_load_kernel() in its present form), but with the QOM approach apparently --property arguments should allow you to parameterise the bootloader directly, without vl.c or qemu-opts having to know about the arguments at all. Unfortunately --property is a long way from working so we are stuck with the status quo or your machine-opts approach until that happens. >> >> A QOM'ified arm_boot could get a "virtual" callback method to check the >> QemuOpts command line args. That way derived classes can decide what >> additional options to accept. >> >> An alternative would be to expect QOM properties of the same name as the >> command line parameters and fail if there isn't one of that name. > > You'd also need vl.c to be able to say "find me the first boot loader > of any kind in the qom tree" so it could set the properties on the > right thing. > > But really qomifying arm_boot doesn't excite me very much -- it > doesn't really get us anything useful in the way that qomifying > SysBus, for instance, does. So my preference is not to have to > tie device tree support to it. > > -- PMM
