[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target
On 06/15/2010 02:04 PM, jes.soren...@redhat.com wrote: From: Jes Sorensen Hi, This set of patches fixes building qemu-kvm for non KVM targets, as reported in http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2984626&group_id=180599 One of the main problem is that we have a tendency to move things from Makefile.objs to Makefile.target in order to be able to use TARGET_I386 etc in hw/*.c files. IMHO we need to start clamping down on this harder and move things into separate files rather than the #ifdef hacks. Hence this patch fixes the short term problem, but there is more work to do for the longer term. It's the other way round. Upstream keeps moving stuff out of Makefile.target, and I move them back during merges, because the only thing I can think of during a merge is "how quickly can I complete this merge". Thanks for tackling this. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target
On 06/15/2010 03:04 PM, Avi Kivity wrote: On 06/15/2010 02:04 PM, jes.soren...@redhat.com wrote: From: Jes Sorensen Hi, This set of patches fixes building qemu-kvm for non KVM targets, as reported in http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2984626&group_id=180599 One of the main problem is that we have a tendency to move things from Makefile.objs to Makefile.target in order to be able to use TARGET_I386 etc in hw/*.c files. IMHO we need to start clamping down on this harder and move things into separate files rather than the #ifdef hacks. Hence this patch fixes the short term problem, but there is more work to do for the longer term. It's the other way round. Upstream keeps moving stuff out of Makefile.target, and I move them back during merges, because the only thing I can think of during a merge is "how quickly can I complete this merge". Thanks for tackling this. Oh, I though you actually moved things back. Anyway, Reviewed-by: Avi Kivity -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target
On 06/15/10 14:04, Avi Kivity wrote: > It's the other way round. Upstream keeps moving stuff out of > Makefile.target, and I move them back during merges, because the only > thing I can think of during a merge is "how quickly can I complete this > merge". > > Thanks for tackling this. I see. I found at least some of the cases I was tackling was because things had moved from .objs to .target because of the TARGET_I386 checks. Trying to use TARGET_I386 in a file that is listed in Makefile.objs causes nasty warnings. I would very much like it if we can be more strict not allowing such changes without a very strong reason in the future :) Part of the problem is of course that there are no easy ways to check for the presence of say HPET since we don't have CONFIG_HPET so TARGET_I386 becomes the easy way :( Cheers, Jes
[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target
On 06/15/10 15:42, Juan Quintela wrote: > On my hpet removal patches, the important bit was that I enabled > #define CONFIG_HPET 1 > > in C land, that makes it easy to do this kind of tests. As it is today, > it is very difficult to test for a feature, as we only have TARGET_* > defines. > > Instead of CONFIG_HPET, we have TARGET_I386. I totally agree, and I'd like to see things like HPET becoming config options. Even for I386 builds, it may not be everybody who wants to build it in. Cheers, Jes
[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target
Jes Sorensen wrote: > On 06/15/10 14:04, Avi Kivity wrote: >> It's the other way round. Upstream keeps moving stuff out of >> Makefile.target, and I move them back during merges, because the only >> thing I can think of during a merge is "how quickly can I complete this >> merge". >> >> Thanks for tackling this. > > I see. I found at least some of the cases I was tackling was because > things had moved from .objs to .target because of the TARGET_I386 > checks. Trying to use TARGET_I386 in a file that is listed in > Makefile.objs causes nasty warnings. > > I would very much like it if we can be more strict not allowing such > changes without a very strong reason in the future :) > > Part of the problem is of course that there are no easy ways to check > for the presence of say HPET since we don't have CONFIG_HPET so > TARGET_I386 becomes the easy way :( On my hpet removal patches, the important bit was that I enabled #define CONFIG_HPET 1 in C land, that makes it easy to do this kind of tests. As it is today, it is very difficult to test for a feature, as we only have TARGET_* defines. Instead of CONFIG_HPET, we have TARGET_I386. Later, Juan.
