Re: [Qemu-devel] [Discussion 00/10] about API hierarchy

[Andreas Färber]

Hi Xuebing,

Am 04.03.2014 03:47, schrieb Xuebing Wang:
> Q2) Does it make sense to remove NEED_CPU_H from qemu-common.h?

IMO not in this way. Work has been ongoing to obsolete NEED_CPU_H by
introducing CPUState in addition to CPUArchState and moving fields into
CPUState, so that less files need to include target-xxx/cpu.h. Your
approach seems to be rather spreading it to more and different files.

Please explain in more detail: Why is code being moved from qom/cpu.h to
vmstate.h for target-alpha?

Concerning gdbstub.h, have you investigated replacing remaining
CPUArchState usages with CPUState, like I started in a previous series?

Concerning memory_mapping.h, have you checked the mailing list archives
for reasons why I didn't use my vaddr there myself? Pointing me to my
HACKING entry does not answer that. ;) (Either vaddr didn't exist yet at
the time or there was some reason not to use it, I would hope!)

An important thing to watch out for when moving includes around is
avoiding (more) circular dependencies. CC'ing Eduardo.

Also note that I still haven't fully rebased my qom-cpu-13 branch yet,
which includes a number of field movements and is likely to clash with
some of your refactorings in CPU/exec/translate files.

Your observation is correct that not all things are in the best shape.
The question is in which way and in which order to address them.
To better judge, what are the immediate gains of your proposals? For
example, I don't spot any Makefile changes in your diffstat that benefit
from a dropped cpu.h include somewhere in terms of build dependencies.
Nor does your series include a proof of concept that something becomes
possible that wasn't before. Understanding the exact advantages would
help me in determining what priority to assign such changes. Thanks.

Regards,
Andreas

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