Re: [Qemu-devel] [PULL for-1.3] QOM CPUState patch queue 2012-11-15

[Eduardo Habkost]

On Wed, Nov 21, 2012 at 06:43:21PM +0100, Andreas Färber wrote:
> Am 15.11.2012 04:06, schrieb Andreas Färber:
> > The following changes since commit ce34cf72fe508b27a78f83c184142e8d1e6a048a:
> > 
> >   Merge remote-tracking branch 'awilliam/tags/vfio-pci-for-qemu-1.3.0-rc0' 
> > into staging (2012-11-14 08:53:40 -0600)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://github.com/afaerber/qemu-cpu.git qom-cpu
> > 
> > for you to fetch changes up to 37507094f350b75c62dc059f998e7185de3ab60a:
> > 
> >   target-i386: Add Haswell CPU model (2012-11-15 03:48:47 +0100)
> > 
> > ----------------------------------------------------------------
> > Andre Przywara (2):
> >       target-i386/cpu: Name new CPUID bits
> >       target-i386/cpu: Add new Opteron CPU model
> > 
> > Andreas Färber (1):
> >       osdep: Move qemu_{open,close}() prototypes
> > 
> > Anthony Liguori (1):
> >       qdev: Split up header so it can be used in cpu.h
> > 
> > Eduardo Habkost (5):
> >       qemu-common.h: Comment about usage rules
> >       qemu-fsdev-dummy.c: Include module.h
> >       vnc-palette.h: Include <stdbool.h>
> >       qemu-config.h: Include headers it needs
> >       target-i386: Add Haswell CPU model
> > 
> > Igor Mammedov (2):
> >       Move qemu_irq typedef out of qemu-common.h
> >       qapi-types.h: Don't include qemu-common.h
> 
> Eduardo, Igor,
> 
> This batch has been pulled into v1.3.0-rc0. Can you please rebase and
> let me know how you would like to proceed?

I just rebased my CPU-DeviceState branch locally. I can send a new
series with the result, if you think it is useful.

I am already expecting the rest of the CPU-DeviceState series to miss
1.3. If you think some of the remaining patches still have a chance of
getting in (especially the qdev-split work), please let me know, so I
can send a rebased version as soon as possible.

Now, talking about post-1.3: I would really like to get some feedback on
"[PATCH 00/17] target-i386: CPU init cleanup for CPU
classes/properties", to see if you think it's a good starting point for
both the CPU classes and the CPU properties work.



> Igor had tried to avoid a new
> qemu-types.h, which iirc didn't completely work out?

Igor was trying to do that, maybe he managed to make qemu-types.h
unnecessary for the 'Monitor' typedef. But we have other 49 typedefs on
qemu-types.h (that were previously on qemu-common.h) that would have to
be moved somewhere else, as well.  :-)

I would love to kill qemu-types.h if possible, but I think we may find
cases where it will be impossible to have a separate header for the
typedefs, if (for example) we have two headers that don't really depend
on each other, but use the typedefs for structs declared on each
other[1].


> 
> Currently I still have five patches queued on qom-cpu-dev branch:
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-dev
> 
> If you're available, I'd be interested in getting this staged during the
> freeze, so that I can continue review of the follow-up series on a
> common basis.

Are you talking about just the 5 patches on qom-cpu-dev? I am absolutely
OK with including them.

> 
> Thanks,
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[1] I mean, I won't be surprised if we find cases like:

foo.h:
  struct Foo { ... };
  struct OtherFooType { ... };
  void foo_func(Foo *f, OtherFooType *ff, Bar *b);

bar.h:
  struct Bar { ... };
  struct OtherBarType { ... };
  void bar_func(Bar *b, OtherBarType *bb, Foo *f);

-- 
Eduardo