Am 15.07.2013 17:29, schrieb Paolo Bonzini: > Il 15/07/2013 17:20, Andreas Färber ha scritto: >> We have some ugly include chains - yes, it shouldn't be here forever. >> Just like the qemu/log.h situation is pretty unsatisfactory (I wouldve >> liked to place log_cpu_state() into qom/cpu.h but it depends in >> qemu-common.h and even ignoring that didn't build for all targets >> depending on include order inside cpu.h and of cpu.h). >> What we need is (a) header(s) that allows use of CPUState type and that >> doesn't use CPUArchState or other target-specifics. I believe the >> benefits of getting rid of CPUArchState outweigh the choice of qom/cpu.h >> here, which has been serving as a dumpbin for some now >> CPUState-dependent functions living in exec.c or cpus.c, too, simply >> because CPUState is guaranteed to be available there and to separate it >> from anything that still needs to be seen through similar to cpu-qom.h >> vs. cpu.h. If you have a spontaneous suggestion I'd be all ears. > > I'm not sure why it couldn't have stayed in cpu-all.h, but I must be > missing something. :)
You're missing TARGET_WORDS_BIGENDIAN on line 39, target_ulong further down, CPUArchState in cpu_copy() and cpu_abort(), etc. By placing it in a header that does not have this baggage, some timer and intc devices in this series were able to drop their dependency on cpu.h in favor of qom/cpu.h and be built in common-obj-y rather than obj-y. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg