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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/01/2012 10:20 AM, Peter Maydell wrote:
> On 1 May 2012 16:09, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 05/01/2012 09:20 AM, Peter Maydell wrote:
>>> This is a bit verbose. Something more like
>>>   pin_connect(s, "int_out[0]", self, "int_set[2]");
>>
>> This is incorrect, it would have to be:
>>
>> Error *err = NULL;
>>
>> if (pin_connect(s, "in_out[0]", self, "int_set[2]",&err)) {
>>    error_propagate(errp, err);
>>    return;
>>
>> }
>>
>>> would be a bit less longwinded. Or even
>>>   connect(TYPE_PIN, s, "int_out[0]", self, "int_set[2]");
>>
>>
>> Not checking for failure is not an option.
>
> 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.

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.

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.

> 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.

Regards,

Anthony Liguori

>
> -- PMM