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: Anthony Liguori
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Tue, 1 May 2012 12:21:34 -0500


On May 1, 2012 10:37 AM, "Peter Maydell" <address@hidden> wrote:
>
> On 1 May 2012 16:26, Anthony Liguori <address@hidden> wrote:
> > On 05/01/2012 10:20 AM, Peter Maydell wrote:
> >> 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.
>
> If you're trying to hotplug a buggily implemented device then
> all bets are off, really.

Its never okay to kill a guest.  We should fail gracefully when possible or simply avoid failing in the first place.

> > 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.
>
> Most of them are simply convenience functions that just
> do "create, configure, wire up, init". (The ones that do
> more than that need fixing anyway.
> > 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.
>
> ...you have redundant code scattered in multiple places instead?

Redundant is the wrong word.  It seems like the code ought to be reduced to a single function call but it really cannot.

>
> >> 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.
>
> Obvious question: why isn't property setting done this way,
> then? Surely it's equally brief and safe to say
>  cpu->level = def_level;
> rather than
>  object_property_set_int(OBJECT(cpu), def->level, "level", &error);

A primary design consideration for QOM was to *not* require using the generic property interface to set properties. That doesnt mean that you can/should access all properties this way. It depends on the specific property.

> I don't particularly object to this sort of "public struct
> vs private struct" object model, it's just not what you've
> actually implemented.

One step at a time.

Regards,

Anthony Liguori

>
> -- PMM


reply via email to

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