Hello! > But Peter C has a better grasp of the current status of > multiarch than I do, so if he prefers using obj-y then > I'm happy to take his recommendation.
I am neutral, and i will accept any solution. OTOH, he agreed with my proposal too, and even promised to pick it up into his patchsets, but suggested to change include pathname to include/hw/arm/cpu.h. And i have the last concern about it because hw/arm/ is a place where board-specific includes are placed. Additionally, we already have three more specific ARM CPU files in include/hw/cpu/, so they just look nice together. And you know... Theoretically... As far as i can understand, multi-arch is a way to enable emulation of heterogeneous systems, which combine different CPUs. Am i right about it? In this case, what if in future we have some heterogeneous HW, where e.g. ARM and x86 are interoperating using system registers? In this case, x86-targeted qemu code would probably have to talk to ARM-targeted one. And having this API separated from the inner CPU guts would only help. Compared to this architectural improvement, obj-y looks like very simple way to ignore, but not to solve the problem. :) So, Peter C, what is your final decision? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia