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

From: Anthony Liguori <anthony@codemonkey.ws>
To: Paul Brook <paul@codesourcery.com>
Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com>,
	peter.maydell@linaro.org, aliguori@us.ibm.com,
	Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
Date: Wed, 08 Feb 2012 10:35:14 -0600	[thread overview]
Message-ID: <4F32A442.1090206@codemonkey.ws> (raw)
In-Reply-To: <201202081615.30937.paul@codesourcery.com>

On 02/08/2012 10:15 AM, Paul Brook wrote:
>> Ok, that sounds more workable :). So i would add my initrd_addr property to
>> the bootloader as a qdev prop as I suggested before, then something like:
>>
>> qemu-system-arm -M verstailepb -property
>> /foo/bar/arm_linux_loader.0,initrd_addr=0x10000000
>
> Yes.
>
> There are various implementation/syntax details to resolve, but in principle I
> think it should work a lot like that.

There's already a qom-set that takes a path, property, and value.  It works with 
Visitors.  To bridge this to the command line, you would need to make a Visitor 
that defined some syntax for mapping strings to types (pretty trivial really).

But before we can even think about this, we need to refactor the device model 
such that we have a clean separation between initial creation (including 
creation of children devices) and initialization that requires properties to be 
set (realization).

I posted a series for the i440fx that started doing this refactoring for the PC.

Regards,

Anthony Liguori

>
> Paul
>