From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
qemu-devel@nongnu.org,
Mark Langsdorf <mark.langsdorf@calxeda.com>
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 [thread overview]
Message-ID: <501A9474.7070609@suse.de> (raw)
In-Reply-To: <CAFEAcA83m1vOie7rzhTnLJnk-sOCxytzmdraYJp8pquYYwWxkg@mail.gmail.com>
Am 02.08.2012 15:48, schrieb Peter Maydell:
> On 2 August 2012 02:16, Andreas Färber <afaerber@suse.de> wrote:
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>> 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
next prev parent reply other threads:[~2012-08-02 14:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-02 1:16 [Qemu-devel] [PATCH RFC for-1.2] arm: Move some ARM devices into libhw Andreas Färber
2012-08-02 13:48 ` Peter Maydell
2012-08-02 14:53 ` Andreas Färber [this message]
2012-08-02 15:01 ` Peter Maydell
2012-08-02 15:58 ` Andreas Färber
2012-08-10 17:15 ` Andreas Färber
2012-08-11 19:12 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501A9474.7070609@suse.de \
--to=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=mark.langsdorf@calxeda.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.