All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: aliguori@us.ibm.com, "Alexander Graf" <agraf@suse.de>,
	qemu-devel@nongnu.org, "Paul Brook" <paul@codesourcery.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
Date: Tue, 21 Feb 2012 19:15:33 +1000	[thread overview]
Message-ID: <CAEgOgz79sz7AuT+W_EHxj-wjfw++NpXVu0intEAHKHY-O2Gpfw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA9x_EQ-vzP3MbigCYN1NxWRdUgAhWh9522dcDLzE-4rYQ@mail.gmail.com>

On Tue, Feb 21, 2012 at 5:56 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 20 February 2012 19:51, Andreas Färber <afaerber@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

  reply	other threads:[~2012-02-21  9:15 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08  7:55 [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition Peter A. G. Crosthwaite
2012-02-08  9:06 ` Paul Brook
2012-02-08 10:11   ` Peter Crosthwaite
2012-02-08 10:44     ` Paul Brook
2012-02-08 11:10       ` Peter Crosthwaite
2012-02-08 11:39         ` Paul Brook
2012-02-08 11:59           ` Peter Crosthwaite
2012-02-08 12:27             ` Paul Brook
2012-02-08 12:41               ` Alexander Graf
2012-02-08 13:04                 ` Peter Crosthwaite
2012-02-08 13:10                   ` Alexander Graf
2012-02-08 13:30                     ` Peter Crosthwaite
2012-02-08 13:35                       ` Alexander Graf
2012-02-08 14:05                         ` Peter Crosthwaite
2012-02-08 14:17                           ` Alexander Graf
2012-02-08 14:20                           ` Paul Brook
2012-02-08 14:39                             ` Peter Crosthwaite
2012-02-08 14:56                               ` Paul Brook
2012-02-08 15:14                                 ` Peter Crosthwaite
2012-02-08 15:57                                   ` Paul Brook
2012-02-08 16:03                                     ` Peter Crosthwaite
2012-02-08 16:15                                       ` Paul Brook
2012-02-08 16:35                                         ` Anthony Liguori
2012-02-09  1:22                                           ` Peter Crosthwaite
2012-02-09 12:03                                             ` Paul Brook
2012-02-08 16:20                                       ` Anthony Liguori
2012-02-08 13:47                 ` Anthony Liguori
2012-02-20 19:43                   ` Peter Maydell
2012-02-20 19:51                     ` Andreas Färber
2012-02-20 19:56                       ` Peter Maydell
2012-02-21  9:15                         ` Peter Crosthwaite [this message]
2012-02-21 10:20                           ` Peter Maydell
2012-02-08 13:41 ` Anthony Liguori
2012-02-09 13:22 ` Andreas Färber
2012-02-10  2:11   ` Peter Crosthwaite

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEgOgz79sz7AuT+W_EHxj-wjfw++NpXVu0intEAHKHY-O2Gpfw@mail.gmail.com \
    --to=peter.crosthwaite@petalogix.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=paul@codesourcery.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.