On Tue, Oct 27, 2015 at 7:18 AM, Pavel Fedin <p.fe...@samsung.com> wrote:
> 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? > > If there are no dependent patches on list that are 2.5 candidate, I suggest we just drop this one for the short term. Is there something on list? I have no objection to the obj-y solution medium term, as there are already multiple users of the ARM CP API using their obj-y privileges to access it. Certainly don't wait on MA to send your patches. These obj-y's will need to be converted en-masse so adding GIC to the list of TBDs is not a big issue IMO. So I would just prepend the obj-y conversion as P1 of the series implementing your GIC CP functionality. Note that multi-arch does not multiple-compile obj-y for the MA build itself. There is still only one compile of obj-y for the MA binary. The basic guideline is: common-obj-y -> Compiled only once absolutely obj-y -> Multiple compiled per output binary arch-obj-y -> Multiple compiled per output binary and multiple compiled per CPU arch within multi-arch build Ideally obj-y eventually evaporates. Genuinely CPU specific stuff and performance sensitive stuff (like the TCG translate+execute) are converted from obj-y to arch-obj-y. The current multi-arch work does this: https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg03929.html Everything else should be common-obj-y. So the follow up is to remove the (mostly false) deps of device land on CPU-target specifics. So we should do what your patch is doing only, on a much bigger scale. But the obj-y conversion won't inhibit multi-arch functionality. Regards, Peter > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia > > >
