Re: [Qemu-devel] [PATCH RFC for-1.2] arm: Move some ARM devices into libhw

[Peter Maydell]

On 2 August 2012 15:53, Andreas Färber <address@hidden> wrote:
> Am 02.08.2012 15:48, schrieb Peter Maydell:
>> On 2 August 2012 02:16, Andreas Färber <address@hidden> wrote:
>>> Signed-off-by: Andreas Färber <address@hidden>
>>> ---
>>>  Hello Peter, here's my current draft for subjecting more arm devices to the
>>>  stricter device checks in libhwX. Please review desired granularity (here:
>>>  fine-grained) and naming (e.g., PL310 vs. l2x0).
>>>  Since this is preparing for a future armeb-softmmu, Anthony's 
>>> CONFIG_ARCH_ARM
>>>  is not going to help here (we would want to turn off many devices for 
>>> armeb).
>>>  The SoCs with references to CPUs in their header are untouched, i.MX31 was
>>>  not yet reviewed for movability.
>>
>> So what's our long term vision here? Every device has a CONFIG_FOO that
>> gets turned on in some default-configs/ file?
>
> The general idea is to set good examples for authors of new devices and
> to prepare for armeb: To me, that calls for disabling all ARM devices
> apart from those whitelisted / strictly needed for BE.
>
> And for me personally to reduce build times when changing CPU things:
> Currently way too many files are needlessly rebuilt because they happen
> to trigger a cpu.h dependency (NEED_CPU_H) due to sitting in the "wrong"
> Makefile.
>
> Another, independent long-term vision would be to place arm files into
> hw/arm/, to put some more structure into the looong list of hw/ files.
> But moving files around would be a task for you to do on your
> arm-devs.next queue to not interfere with any ongoing device work. The
> difference between devices and machine stuff would then be obj-y vs.
> hw-obj-y as Anthony explained to me in the kvm/ context.
>
>> What are the 'stricter checks' you mention?
>
> Poisoning certain identifiers (Blue's initiative, I believe), no
> explicit guest-dependent swaps and other limitations incurred by
> cpu.h-less headers.
>
>>> +hw-obj-$(CONFIG_PL310) += arm_l2x0.o
>>
>> Maybe we should have named the source file pl310.c...
>
> That was one of my RFC points - not sure how to interpret the header: Is
> this multiple devices in one? Or different names for the same thing?
> I just found it looked nicer this way. ;)

Basically the (hardware) device was renamed to match the other PL*,
but from an engineering pov the PL310 is just the newer version of
the L220 (which in turn is the newer version of the L210); they're all
very similar from a programmer's view perspective. I think 'l2x0' comes
from what the kernel calls it.

> Independent of that, do we need to separate things on that granularity
> at all? Or just do CONFIG_PL or something?
> In practice, it seemed that usage of these devices is rather fragmented
> (not all boards use all PLxxx devices) so that per-device config names
> as in master allow for fine-grained control of which devices get built
> if only armeb-softmmu were to be built;
> on the other hand if that seems too complicated the alternative question
> to ask would be, are all PLxxx devices theoretically capable of being
> used for armeb as well?

They should in theory be OK on a big-endian system, but then in theory
just about any device should be OK on a big endian system: device/system
endianness and CPU endianness are orthogonal.

-- PMM