[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition |
Date: |
Mon, 20 Feb 2012 20:51:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 |
Am 20.02.2012 20:43, schrieb Peter Maydell:
> On 8 February 2012 13:47, Anthony Liguori <address@hidden> wrote:
>> On 02/08/2012 06:41 AM, Alexander Graf wrote:
>>> Yeah, basically the variable flow goes:
>>>
>>> vl.c -> machine_opts -> machine_init() -> device properties ->
>>> device_init()
>>
>> And the rationale is that machine_init() will do nothing other than use QOM
>> primitives to create a set of expected devices and set up their properties
>> such that a person (or management tool) could do everything that
>> machine_init() is doing.
>
> So I think this flow is wrong (and indeed I didn't implement it that way in
> my patches to add machine opts for kernel/initrd/dtb) -- the machine_init()
> shouldn't have to care about this because we don't want to have to modify
> a huge set of machine init functions every time we add an extra option
> that only the boot loader cares about.
>
> 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.
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.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, (continued)
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Crosthwaite, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Paul Brook, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Crosthwaite, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Paul Brook, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Anthony Liguori, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Crosthwaite, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Paul Brook, 2012/02/09
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Anthony Liguori, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Anthony Liguori, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Maydell, 2012/02/20
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition,
Andreas Färber <=
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Maydell, 2012/02/20
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Crosthwaite, 2012/02/21
- Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Peter Maydell, 2012/02/21
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Anthony Liguori, 2012/02/08
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition, Andreas Färber, 2012/02/09