[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Immutable qdev properties
From: |
Markus Armbruster |
Subject: |
[Qemu-devel] Re: Immutable qdev properties |
Date: |
Mon, 24 Aug 2009 15:04:05 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
Gerd Hoffmann <address@hidden> writes:
> On 08/24/09 11:05, Markus Armbruster wrote:
>
>> iobase[] will start as whatever the user specifies in -device,
>> defaulting to { -1, -1 }, then revert to { 0x441, 0x443 } when the
>> device is initialized. Not sure whether this is a problem.
>
> The ioport properties should reflect the values actually used, even in
> case they can not be configured. So in case a ISA device finds '-1'
> aka 'not specified by the user', it should fill in (and use) the
> default value. See also below ...
Works for me.
>> Taking a step back, the general problem is "immutable" qdev properties,
>> i.e. properties that aren't configurable. I think it would be good to
>> agree on a common method there, and document it.
>
> On a even broader view: how to handle invalid property values?
Good point.
> Having a device support one fixed I/O port is just a special case of
> that. Other ISA devices usually can be configured to a few possible
> I/O bases using dip switches (sound cards for example). But the
> possible values are usually fairly limited.
>
> In case the user specifies a impossible iobase we can
>
> (1) ignore it and use defaults instead.
> (2) fix it (pick nearest possible value or so).
> (3) fail.
>
> #3 is probably the most sane,
Agree.
> but that depends on the
> init()-callback-can-fail patches ...
Yes.
[Qemu-devel] [PATCH 1/3] Move watchdog, watchdog_action, give them internal linkage, Markus Armbruster, 2009/08/21
[Qemu-devel] [PATCH 2/3] Clean up upcast from PCIDevice to I6300State, Markus Armbruster, 2009/08/21
Re: [Qemu-devel] [PATCH 2/3] Clean up upcast from PCIDevice to I6300State, Paul Brook, 2009/08/24