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