On Wed, Jun 14, 2017 at 07:23:56PM +0300, Roman Kagan wrote: > On Wed, Jun 14, 2017 at 10:53:25AM -0300, Eduardo Habkost wrote: > > On Tue, Jun 06, 2017 at 09:19:37PM +0300, Roman Kagan wrote: > > > Multiple entities (e.g. VMBus devices) can use the same SINT route. To > > > make their lives easier in maintaining SINT route ownership, make it > > > reference-counted. Adjust the respective API names accordingly. > > > > > > Signed-off-by: Roman Kagan <rka...@virtuozzo.com> > > > > Isn't it easier to reuse existing refcounting infrastructure > > here? Is it overkill to make it a QOM object? (struct Object has > > 40 bytes) > > Normally the guests use a sint route per cpu or less. So no, the space > overhead is not an issue. > > I also wanted to reuse regular QOM refcounting so I QOM-ified it at > first. However, while hammering out the design, I found no appropriate > place in the QOM hierachy where to stick these objects so we dropped the > idea. > > If I get your proposal right you suggest to leave it unattached instead. > That should probably work; however, looking at all the boilerplate code > this would entail, including OBJECT casts, I'm not sure it would save > anything. Do you think it's worth reworking into QOM?
I just noticed I didn't reply to this, sorry. I'm also not sure it is worth reworking into QOM, so I guess it's up to you. About placing the object in the QOM hierarchy, I don't think that would be a problem. Objects without a parent are safer, as long as reference counting is properly tracked. About the OBJECT casts, I guess that's a common issue. I'm considering proposing making object_ref()/object_unref() macros that use OBJECT() automatically. -- Eduardo
