From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:42898)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Rv8fz-0005lM-SR
	for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:39:21 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Rv8fq-00074y-Cf
	for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:39:15 -0500
Received: from mail-bk0-f45.google.com ([209.85.214.45]:59325)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1Rv8fq-00074c-7P
	for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:39:06 -0500
Received: by bkue19 with SMTP id e19so437305bku.4
	for <qemu-devel@nongnu.org>; Wed, 08 Feb 2012 06:39:04 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <201202081420.54442.paul@codesourcery.com>
References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com>
	<D5DC4BEC-516E-473D-BE3D-454D1C9AF91B@suse.de>
	<CAEgOgz6js39Q6KC+S_X5V0k-m3G154x07e=-DGMB-hbaJbEUrw@mail.gmail.com>
	<201202081420.54442.paul@codesourcery.com>
Date: Thu, 9 Feb 2012 00:39:04 +1000
Message-ID: <CAEgOgz7xDQeQeWVwwrUOuQL1AH5Japz7fD_2GD+kPcNS2F1_9Q@mail.gmail.com>
From: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Content-Type: multipart/alternative; boundary=000e0cdfc78676f76e04b874db37
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
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: Paul Brook <paul@codesourcery.com>
Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org

--000e0cdfc78676f76e04b874db37
Content-Type: text/plain; charset=ISO-8859-1

2012/2/9 Paul Brook <paul@codesourcery.com>

> > So if we consider this bootloader a device and its -dtb argument a
> property
> > of that device, then what you are implying is that every device property
> of
> > every device in a machine must be managed by the machine model? Isn't the
> > dynamic machine model work that is in progress is trying to get away the
> > approach where fixed machine models have to micromanage all their
> attached
> > devices? with the ultimate goal of -no-machine how will the bootloader
> get
> > this dtb argument?
>
> My expectation is that we have some way for the machine description to tag
> objects/properties that pap to the generic commandline options.  In the
> same
> way that we'd probably want to tag the default PCI bus, or UARTs for
> matching
> with the -serial commandline.  Some of these can be guessed, others you
> need
> the machine description to tell you.
>
> Paul
>

Ok, so it seems that for command line driven arguments the policy is with
standard arguments such as -dtb, the machine model must get it on the
device behalf and instantiate the device, and that fits in with this patch.

Its the other problem I am more worried about, i.e. when I -device
instantiate my bootloader with an existing machine how do I get my ram_size
and board_ID? The no machine opts for devices policy makes this impossible
such that I would have to pass in board_id and ram_size to
the boot-loader on the command line. Is there any acceptable way where the
machine model can make something globally available to devices for the
purpose of instantiating them with -device?

--000e0cdfc78676f76e04b874db37
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2012/2/9 Paul Brook <span dir=3D"ltr">&l=
t;<a href=3D"mailto:paul@codesourcery.com">paul@codesourcery.com</a>&gt;</s=
pan><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt; So if we consider this bootloader a device and its -=
dtb argument a property<br>
&gt; of that device, then what you are implying is that every device proper=
ty of<br>
&gt; every device in a machine must be managed by the machine model? Isn&#3=
9;t the<br>
&gt; dynamic machine model work that is in progress is trying to get away t=
he<br>
&gt; approach where fixed machine models have to micromanage all their atta=
ched<br>
&gt; devices? with the ultimate goal of -no-machine how will the bootloader=
 get<br>
&gt; this dtb argument?<br>
<br>
</div>My expectation is that we have some way for the machine description t=
o tag<br>
objects/properties that pap to the generic commandline options. =A0In the s=
ame<br>
way that we&#39;d probably want to tag the default PCI bus, or UARTs for ma=
tching<br>
with the -serial commandline. =A0Some of these can be guessed, others you n=
eed<br>
the machine description to tell you.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Paul<br>
</font></span></blockquote></div><br><div>Ok, so it seems that for command =
line driven arguments the policy is with standard arguments such as -dtb, t=
he machine model must get it on the device behalf and instantiate the devic=
e, and that fits in with this patch.</div>
<div><br></div><div>Its the other problem I am more worried about, i.e. whe=
n I -device instantiate my bootloader with an existing machine how do I get=
 my ram_size and board_ID? The no machine opts for devices policy makes thi=
s impossible such that I would have to pass in board_id and ram_size to the=
=A0boot-loader=A0on the command line. Is there any acceptable way where the=
 machine model can make something globally available to devices for the pur=
pose of instantiating them with -device?</div>
<div><br></div><div><br></div>

--000e0cdfc78676f76e04b874db37--