[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:09:26 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/01/2012 09:20 AM, Peter Maydell wrote:
On 1 May 2012 15:06, Anthony Liguori<address@hidden>  wrote:
Do you mean:

-    qdev_connect_gpio_out(&dev->qdev, 0, irq_set[2]);
+    pin_connect_qemu_irq(&s->int_out[0], irq_set[2]);

There are three ways to do this:

1) pin_connect_qemu_irq(i8259_get_int_out(s), irq_set[2]);

No good unless you're autogenerating all those accessor functions.

2) pin_connect_qemu_irq(&s->int_out[0], irq_set[2]);

Exposes the whole of the struct (including all the private
memmbers) to anything that wants to use it. As you say
later on in the email, this requires splitting everything up
into two structs, one for "publicly accessible" and one for
"private implementation"...which your series doesn't seem
to do at the moment.

3) pin_connect_qemu_irq(PIN(object_get_child(s, "int_out[0]")), irq_set[2]);

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.

(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(). These types of functions should go away in favor of proper modeling of SoCs/SuperIO chips.


Anthony Liguori

-- PMM

reply via email to

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