qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Tue, 1 May 2012 16:20:09 +0100

On 1 May 2012 16:09, Anthony Liguori <address@hidden> 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.
(Obviously we would provide APIs for the occasional use case
that really did want to do "connect if possible and do something
else in case of failure", but that's definitely not the
common case.)

>> (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. That's why
I want the standard native "connect this thing to this
other thing" function to be short and simple.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]