[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Tue, 01 May 2012 10:26:27 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/01/2012 10:20 AM, Peter Maydell wrote:
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);


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.


Anthony Liguori

-- PMM

reply via email to

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