qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]