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

[Anthony Liguori]

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);
> >    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