Re: [Qemu-devel] [PATCH v2] arm: add device tree support

[John Williams <john.williams@petalogix.com>]

On Wed, Feb 1, 2012 at 12:37 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/31/2012 07:44 PM, Alexander Graf wrote:
>>
>>
>> On 01.02.2012, at 02:35, Paul Brook wrote:
>>
>>>> We could also just change machine->init() and pass the dtb in there. In
>>>> a
>>>> QOM world these would become machine device properties anyways.
>>>>
>>>>    machine->init(ram_size, boot_devices,
>>>>                  kernel_filename, kernel_cmdline, initrd_filename,
>>>> cpu_model);
>>>>
>>>> Essentially we shouldn't treat -dtb any different than -kernel or
>>>> -initrd.
>>>> It's also useful for more than ARM, namely embedded ppc systems. But I
>>>> can
>>>> easily post a follow-up patch for those.
>>>
>>>
>>> Changing machine->init means you have to touch every single board file,
>>> and
>>> clone the exact same code for every machine that uses arm_boot.c.  All of
>>> which will be rewritten in the near future.
>>
>>
>> Well, the dt file name would have to be passed into the generic arm_boot.c
>> function, yes. But that's something that we need to do at one point in time
>> either way, because machines will want to have default dtb file names.
>>
>>> machine->init is a particularly suckiy interface to start with, we want
>>> to be
>>> using it less, not more.  It's not like we're going support multiple
>>> machine
>>> instanced.  At least not before machine->init is removed altogether.
>>
>>
>> I do see your point on not extending legacy interfaces though and not
>> bloating up the patch. In fact, I'm indifferent enough on the actual
>> implementation atm, as long as the command line interface (or whatever the
>> user sees) is reasonably sane. And it is IMHO. So if it makes everything
>> easier, do it using a global, but keep in mind that this will need
>> refactoring.
>
>
> Globals are even worse!
>
> Can't you hear the kernel loader begging to be turned into a device?  It's
> pleading with us to stop abusing other parts of QEMU and make it a first
> class citizen of QEMU.

Is there some kind of initialisation phase where such a device can do its thing?

Unless I'm missing something a "loader" device will be racing the rest
of the VM after reset to populate the memory with the desired
contents, no?

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663