[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC for-1.2] arm: Move some ARM devices into lib
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC for-1.2] arm: Move some ARM devices into libhw |
Date: |
Thu, 02 Aug 2012 16:53:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
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. ;)
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?
>> +hw-obj-$(CONFIG_STELLARIS_ENET) += stellaris_enet.o
>
> Why just this stellaris device and not the others?
I sent this out to comply with the rule of having a patch on the list by
Soft Freeze date, I did not find the time to complete/update it. Either
there's CPU/swap dependencies in the other files or I did not try to
device'ify them yet.
>> -obj-y += pl041.o lm4549.o
>> +obj-y += lm4549.o
>
> If we're moving the pl041 we should move its accompanying codec
> (the lm4549) too, especially since the pl041 is definitely ARM
> only but the lm4549 could be used on other platforms in theory.
There was a merge conflict. The lm4549.o did not seem to exist when I
put together the original patch. And the file names are not exactly
telling, you'll have to admit. So I didn't check on that one yet, it got
late enough...
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg