On Tue, Jan 18, 2011 at 11:09:01AM -0600, Anthony Liguori wrote: > >>But we also need to provide a compatible interface to management tools. > >>Exposing the device model topology as a compatible interface > >>artificially limits us. It's far better to provide higher level > >>supported interfaces to give us the flexibility to change the device > >>model as we need to. > >How do you want to change qdev to keep the guest and management tool > >view stable while branching off kvm sub-buses? > > The qdev device model is not a stable interface. I think that's > been clear from the very beginning. > And what was the reason it was declared not stable? May be because we were not sure we will do it right from the start, so change will be needed later. But changes should bring qdev closer to reflect what guest expect device topology to look like. This will bring us to stable state as close possible. We need this knowledge and stability in qdev for device path creation. Both kind of device paths: OF and the one we use for migration. To create OF device path we need to know topology as seen by a guest (and guest does not care how isa bus is implemented internally inside south bridge), to create device path used for migration we need stability, otherwise change in qdev topology will break migration. All this artificial buses you propose to add move us in opposite direction and make qdev useless for anything but .... well for anything. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
