qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).