Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition

[Peter Crosthwaite]

On Tue, Feb 21, 2012 at 5:56 AM, Peter Maydell <address@hidden> wrote:
> On 20 February 2012 19:51, Andreas Färber <address@hidden> 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