On Sun, Apr 01, 2012 at 12:13:18PM +0300, Gleb Natapov wrote:
> On Sun, Apr 01, 2012 at 12:06:16PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Apr 01, 2012 at 11:26:18AM +0300, Gleb Natapov wrote:
> > > On Sun, Apr 01, 2012 at 11:22:33AM +0300, Michael S. Tsirkin wrote:
> > > > > And if pci-hotplug could be done as cpu-hotplug, then it would
> > > > > simplify pci-hotplug
> > > > > (guest would only need to read PCI_BASE) and probably it would be
> > > > > possible to unify hotplug
> > > > > code for pci/cpu. But that for sure will break compatibility.
> > > >
> > > > Which isn't really acceptable.
> > > >
> > > I do not think it should be taken for granted. We should be able to get
> > > rid of a crud once in a while.
> >
> > In general, yes. It needs to be well planned several years in
> > advance though. Something like
> > http://www.kernel.org/doc/Documentation/feature-removal-schedule.txt
> > might be a model.
> >
> No nearly the same. We do not drop any features, we just reimplementing
> it differently. Since QEMU ships with the bios image that suppose to
> work with it preserving old bios compatibility shouldn't be considered to
> much IMO. Migration from qemu-1.0 to qemu-1.1 -M pc-1.0 should work
> though. By adding more craft now we make cleanup harder later.
>
> > Breaking compatibility would bring very little
> > gain in this case though, right?
> >
> It will clean up code instead of adding more and will allow reuse of
> hotplug code in QEMU and bios between pci/cpu/memory.
>
Just to clarify I am not against your approach per se. We discussed both
points Igor and Alex are bringing now with you on IRC and you convinced me
that your approach is good enough. It shows that IRC is not a proper
channel to discuss thous thing since discussion have to be repeated on
ML anyway, so I bring my points from that discussion here for
consideration by others.
--
Gleb.
