Am 19.01.2013 23:06, schrieb Paolo Bonzini: > Il 19/01/2013 19:11, Andreas Färber ha scritto: >>>> The patches are mostly mechanical substitutions, and there is no >>>> user-visible change---neither in total build time, nor in the files that >>>> are linked into the executables. >> Without having tested this yet I want to remind that it is necessary for >> qom/cpu.c to be built twice > > Hmm, it's not anymore actually (since libuser was removed). It hasn't > been built twice for a month and apparently nothing broke.
I surely didn't ack that. Have you actually tested linux-user to verify it works? It might lead to unexpected CPUState field accesses. >> , to not run into similar issues like >> util/oslib-posix.c. > > The only dependency is > > #if !defined(CONFIG_USER_ONLY) > int kvm_fd; > bool kvm_vcpu_dirty; > #endif > struct KVMState *kvm_state; > struct kvm_run *kvm_run; > > Plenty of other fields are meaningless for !CONFIG_USER_ONLY but are > unconditionally present in struct CPUState. Given this inconsistency, > why is it still useful to build it twice? You are judging based on master. I have some more code movements queued (qom-cpu-8) and I believe it was Anthony who insisted on suppressing those unneeded user-only fields even if they were unconditional in CPU_COMMON before. qom/cpu.c is not intended to remain so small forever - any cpu_* code that does not depend on CPUArchState can find a new home there. cpu_interrupt() is being moved to qom/cpu.h and cpu_reset_interrupt() to qom/cpu.c for instance. And I'm working on refactoring CPU VMState, that either requires #ifdef'ery or lots of new stubs beyond what Eduardo added. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
