-Original Message-
From: Pavel Fedin [mailto:p.fe...@samsung.com]
Sent: 2015年10月28日 19:13
To: 'Peter Crosthwaite'; 'Paolo Bonzini'
Cc: 'Peter Maydell'; 'Shlomo Pongratz'; 'QEMU Developers'; Shlomo Pongratz
Subject: RE: [Qemu-devel] [P
Hello!
> Ok, so decided. I will convert my code, test the build and send a small
> patch for this soon,
> perhaps today.
arm_gicv3_kvm.o is already in obj-y, and arm_gicv3_common.o does not use any
of those definitions. So, nothing to move, there will be no patch.
So far, we have only this
Hello!
> 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?
For 2.5, AFAIK, no. Unless Shlomo suddenly comes up with clean GICv3
implementation which could be quickly accepted.
I wanted to upst
On Tue, Oct 27, 2015 at 7:18 AM, Pavel Fedin 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
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 patchse
On 27 October 2015 at 12:02, Pavel Fedin wrote:
>> We have plenty of precedent in tree for interrupt controllers being
>> compiled as arch-specific for reasons such as this. Can we just
>> promote GIC to an obj-y (much the same way the KVM GIC or V7MNVIC are
>> promoted)? You should them have acce
Hello!
> We have plenty of precedent in tree for interrupt controllers being
> compiled as arch-specific for reasons such as this. Can we just
> promote GIC to an obj-y (much the same way the KVM GIC or V7MNVIC are
> promoted)? You should them have access to cpu.h and the CP interface.
Huh, ind
Hello!
> > include/hw/cpu/arm.h | 308
> > +++
>
> I think this would be hw/arm/cpu.h
Sorry for split-reply, forgot to look at this...
include/hw/arm is for board classes, isn't it?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics
On Mon, Oct 26, 2015 at 12:46 AM, Pavel Fedin wrote:
> Includes, which reside in target-arm, are very problematic to use from code
> which is considered target-independent by the build system (for example,
> hw/intc/something.c). It happens because they depend on config-target.h,
> which is unreac
Includes, which reside in target-arm, are very problematic to use from code
which is considered target-independent by the build system (for example,
hw/intc/something.c). It happens because they depend on config-target.h,
which is unreachable in this case. This creates problems for example for
GICv
10 matches
Mail list logo
