Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 1 May 2012 16:26, Anthony Liguori <address@hidden> wrote:
> On 05/01/2012 10:20 AM, Peter Maydell wrote:
>> The assumption is that failure to connect is a fatal error,
>> and we can happily just assert()/hw_error()/etc.
>
> So that means that we have a bug from someone miss-typing, instead of your
> hotplug attempt failing with an error, your entire guest is destroyed.  That
> doesn't sound very nice to me.

If you're trying to hotplug a buggily implemented device then
all bets are off, really.

> Device initialization should never exit() (unless you really hit a fatal
> error like OOM).
>
>
>>>> (No, this doesn't do compile time type checking. I don't
>>>> think that's a problem particularly, or at least not enough
>>>> of one to justify not doing it this way. The object model we
>>>> have is dynamic and does things at runtime...)
>>>
>>>
>>> Correctness is more important to me than brevity.
>>>
>>> And really, we should focus on killing things like i8259_init().
>>
>>
>> Functions like i8259_init() exist precisely because
>> QOM/qdev don't provide brevity and people trying to
>> use these devices do in fact value brevity.
>
>
> No, they exist because we aren't modeling correctly.

Most of them are simply convenience functions that just
do "create, configure, wire up, init". (The ones that do
more than that need fixing anyway.)

> i8259_init() is doing a few different things at once.
> Once you split things between init and realize, you no longer
> have long chunks of redundant code.

...you have redundant code scattered in multiple places instead?

>> That's why
>> I want the standard native "connect this thing to this
>> other thing" function to be short and simple.
>
>
> With my previous proposal, it's just:
>
> s->irq_in = &b->int_out[0];
>
> This is why I like exposing public members in structures.  It's brief and
> safe.

Obvious question: why isn't property setting done this way,
then? Surely it's equally brief and safe to say
 cpu->level = def_level;
rather than
 object_property_set_int(OBJECT(cpu), def->level, "level", &error);

I don't particularly object to this sort of "public struct
vs private struct" object model, it's just not what you've
actually implemented.

-- PMM