From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPEhs-0001I9-BQ for qemu-devel@nongnu.org; Tue, 01 May 2012 11:09:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPEhq-0001V5-Cd for qemu-devel@nongnu.org; Tue, 01 May 2012 11:09:35 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:63433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPEhq-0001SI-7V for qemu-devel@nongnu.org; Tue, 01 May 2012 11:09:34 -0400 Received: by yenr5 with SMTP id r5so3037236yen.4 for ; Tue, 01 May 2012 08:09:32 -0700 (PDT) Message-ID: <4F9FFCA6.5070706@codemonkey.ws> Date: Tue, 01 May 2012 10:09:26 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4F9D797E.500@ilande.co.uk> <4F9D97F3.8080608@codemonkey.ws> <4F9E5028.7010306@redhat.com> <4F9E82C7.10706@ilande.co.uk> <4F9E9268.70408@redhat.com> <4F9E9569.5000700@redhat.com> <4F9FD997.9000403@redhat.com> <4F9FDA38.6030108@redhat.com> <4F9FDB80.4020604@redhat.com> <4F9FDEBC.2030806@redhat.com> <4F9FEA24.3070603@codemonkey.ws> <4F9FEDFE.3030403@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Cave-Ayland , Avi Kivity , qemu-devel@nongnu.org On 05/01/2012 09:20 AM, Peter Maydell wrote: > On 1 May 2012 15:06, Anthony Liguori 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); 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. > (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. Regards, Anthony Liguori > > -- PMM