On May 1, 2012 10:37 AM, "Peter Maydell" <peter.mayd...@linaro.org> wrote:
> On 1 May 2012 16:26, Anthony Liguori <anth...@codemonkey.ws> 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
> > hotplug attempt failing with an error, your entire guest is destroyed.
> > 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;
> > This is why I like exposing public members in structures. It's brief
> > 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
> 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.
> -- PMM