All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com>,
	qemu-devel@nongnu.org, afaerber@suse.de, agraf@suse.de
Subject: Re: [Qemu-devel] [RFC] Proposal for hw/ split
Date: Mon, 11 Mar 2013 12:54:34 +0100	[thread overview]
Message-ID: <513DC5FA.30205@redhat.com> (raw)
In-Reply-To: <CAFEAcA8MBOV897+oXWC0ZkwFSZKxT4ujyrjbKqZOfNVBhBfpBg@mail.gmail.com>

Il 11/03/2013 12:31, Peter Maydell ha scritto:
> On 11 March 2013 11:17, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> - Files go in hw/ARCH/ if they used to be in hw/ARCH/Makefile.objs and
>>   they define multiple devices (example: hw/arm/tc6393xb.c)
> 
> Why are multiple devices in one file a bad thing (or at least, a
> thing that should determine where a file lives)? Should piix_pci.c
> move to hw/i386 because it happens to define four devices?

Two of the devices are different parts of the same device.  Basically
the part that is only on SysBus vs. the part that is visible on the PCI bus.

The other two should indeed be moved to hw/isa/piix3.c (on my todo list).

> Basically I disagree that trying to move more things into hw/$ARCH
> serves any useful purpose. The split-by-subsystem stuff looks good.
> 
>> == hw/arm ==
>> hw/a15mpcore.c                               hw/arm/a15mpcore.c
> 
> One device.
> 
>> hw/a9mpcore.c                                hw/arm/a9mpcore.c
> 
> One device.
> 
>> hw/arm11mpcore.c                             hw/arm/arm11mpcore.c
> 
> Two devices but I can split them if you insist.

These are little more than SoC containers, aren't they?

>> hw/kvm/arm_gic.c                             hw/arm/kvm/arm_gic.c
> 
> If we're going to move kvm specific devices out of hw/kvm I'd
> rather they just went in hw/. It's an implementation detail that
> a device's back end is KVM specific, so kvm_arm_gic.c should go
> alongside arm_gic.c.

I moved them to hw/ARCH because they really depend on the host kernel.
Even the very same device might have a different interface on a
different kernel.  But I can certainly move these to hw/SUBSYSTEM/kvm.

(I think you said you disagree, but the next step for me would be to
move hw/ARCH to target-ARCH/hw).

>> hw/strongarm.c                               hw/arm/strongarm.c
> 
> We could split the individual devices out into files, which would
> leave sa1110_init() itself (which kind of wants to be a SoC
> container eventually I guess).
> 
>> hw/tc6393xb.c                                hw/arm/tc6393xb.c
> 
> This is only a single device. (It happens to be a not-converted-to-qdev
> device.)

Right, I'll move it to hw/display.

Paolo

  reply	other threads:[~2013-03-11 11:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11 11:17 [Qemu-devel] [RFC] Proposal for hw/ split Paolo Bonzini
2013-03-11 11:31 ` Peter Maydell
2013-03-11 11:54   ` Paolo Bonzini [this message]
2013-03-11 12:39     ` Peter Maydell
2013-03-11 12:44       ` Paolo Bonzini
2013-03-11 13:08         ` Peter Maydell
2013-03-11 13:12           ` Paolo Bonzini
2013-03-11 13:19       ` Markus Armbruster
2013-03-11 11:52 ` Edgar E. Iglesias
2013-03-11 13:37 ` Stefan Hajnoczi
2013-03-12  6:48 ` Richard Henderson
2013-03-12  7:33   ` Paolo Bonzini

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=513DC5FA.30205@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=peter.crosthwaite@petalogix.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.