Patchwork [for-1.4,v4,01/12] ppc: Move Mac machines to hw/ppc/

login
register
mail settings
Submitter Andreas Färber
Date Jan. 24, 2013, 9:03 a.m.
Message ID <1359018245-24344-2-git-send-email-afaerber@suse.de>
Download mbox | patch
Permalink /patch/215272/
State New
Headers show

Comments

Andreas Färber - Jan. 24, 2013, 9:03 a.m.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 hw/cuda.c                                 |    2 +-
 hw/grackle_pci.c                          |    2 +-
 hw/heathrow_pic.c                         |    2 +-
 hw/ide/macio.c                            |    6 +++---
 hw/mac_nvram.c                            |    2 +-
 hw/macio.c                                |    2 +-
 hw/openpic.c                              |    2 +-
 hw/ppc/Makefile.objs                      |    9 +++++----
 hw/{ppc_mac.h => ppc/mac.h}               |    0
 hw/{ppc_newworld.c => ppc/mac_newworld.c} |   28 ++++++++++++++--------------
 hw/{ppc_oldworld.c => ppc/mac_oldworld.c} |   26 +++++++++++++-------------
 hw/unin_pci.c                             |    2 +-
 12 Dateien geändert, 42 Zeilen hinzugefügt(+), 41 Zeilen entfernt(-)
 rename hw/{ppc_mac.h => ppc/mac.h} (100%)
 rename hw/{ppc_newworld.c => ppc/mac_newworld.c} (98%)
 rename hw/{ppc_oldworld.c => ppc/mac_oldworld.c} (97%)
Peter Maydell - Jan. 25, 2013, 10:43 a.m.
On 24 January 2013 09:03, Andreas Färber <afaerber@suse.de> wrote:
> [PATCH for-1.4 v4 01/12] ppc: Move Mac machines to hw/ppc/

...so why is a big code movement patch 1.4 material?
I would prefer us to wait for 1.5, and then we have a
reasonable chance of saying "release goal for 1.5 is to
have moved all the arch-specific hw files to their new homes".
If we commit this for 1.4 then at 1.4 release the source tree
will be in an odd halfway statet.

-- PMM
Alexander Graf - Jan. 25, 2013, 10:52 a.m.
Am 25.01.2013 um 11:43 schrieb Peter Maydell <peter.maydell@linaro.org>:

> On 24 January 2013 09:03, Andreas Färber <afaerber@suse.de> wrote:
>> [PATCH for-1.4 v4 01/12] ppc: Move Mac machines to hw/ppc/
> 
> ...so why is a big code movement patch 1.4 material?
> I would prefer us to wait for 1.5, and then we have a
> reasonable chance of saying "release goal for 1.5 is to
> have moved all the arch-specific hw files to their new homes".
> If we commit this for 1.4 then at 1.4 release the source tree
> will be in an odd halfway statet.

It already is. Check out the current source tree.


Alex

> 
> -- PMM
Andreas Färber - Jan. 25, 2013, 12:49 p.m.
Am 25.01.2013 11:43, schrieb Peter Maydell:
> On 24 January 2013 09:03, Andreas Färber <afaerber@suse.de> wrote:
>> [PATCH for-1.4 v4 01/12] ppc: Move Mac machines to hw/ppc/
> 
> ...so why is a big code movement patch 1.4 material?
> I would prefer us to wait for 1.5, and then we have a
> reasonable chance of saying "release goal for 1.5 is to
> have moved all the arch-specific hw files to their new homes".
> If we commit this for 1.4 then at 1.4 release the source tree
> will be in an odd halfway statet.

You so far refused to have new SoCs/devices put in hw/arm/. Doing so
does keep consistency but creates more work moving them later.

In this case I preferred to do my refactorings on top of the desired
file structure rather than moving them later and loosing easy access to
git-blame history. The movement is a non-functional change, was decided
before the Soft Freeze, has no impact on 1.4 quality. (The following
device refactorings are another matter, but you know why we're under
pressure there.)

The whole of devices is in a halfway-converted state FWIW. As with
Coding Style we need to be aware of where we want to go, keep an eye on
this for incoming devices and gradually improve things.
Finding machines affected by certain CPU refactorings is tedious today;
having, e.g., all m68k machines in hw/m68k/ will make this much easier.

For devices that don't explicitly use a CPU I'm more conservative than
Alex with moving them around, but in the worst case we can move them
again later. For example, when PReP machines use chipsets such as i82378
I still prefer hw/ over hw/ppc/ even if unused in x86 pc/q35 machines
today. Similarly for Mac devices I don't know if some Intel Mac might
reuse any subset thereof, so it's unclear to me where to draw the line.
For exynos or imx or omap or pxa that's pretty clear IMO.

Cheers,
Andreas
Peter Maydell - Jan. 25, 2013, 1:33 p.m.
On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
> Am 25.01.2013 11:43, schrieb Peter Maydell:
>> ...so why is a big code movement patch 1.4 material?
>> I would prefer us to wait for 1.5, and then we have a
>> reasonable chance of saying "release goal for 1.5 is to
>> have moved all the arch-specific hw files to their new homes".
>> If we commit this for 1.4 then at 1.4 release the source tree
>> will be in an odd halfway statet.
>
> You so far refused to have new SoCs/devices put in hw/arm/. Doing so
> does keep consistency but creates more work moving them later.

I haven't *refused*. I just haven't seen a consensus about what
we want the filesystem layout to be, in the absence of which I
haven't seen any great reason to change from the current setup.
If we have that consensus then fine, we can move things around.

-- PMM
Alexander Graf - Jan. 25, 2013, 1:37 p.m.
On 25.01.2013, at 14:33, Peter Maydell wrote:

> On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
>> Am 25.01.2013 11:43, schrieb Peter Maydell:
>>> ...so why is a big code movement patch 1.4 material?
>>> I would prefer us to wait for 1.5, and then we have a
>>> reasonable chance of saying "release goal for 1.5 is to
>>> have moved all the arch-specific hw files to their new homes".
>>> If we commit this for 1.4 then at 1.4 release the source tree
>>> will be in an odd halfway statet.
>> 
>> You so far refused to have new SoCs/devices put in hw/arm/. Doing so
>> does keep consistency but creates more work moving them later.
> 
> I haven't *refused*. I just haven't seen a consensus about what
> we want the filesystem layout to be, in the absence of which I
> haven't seen any great reason to change from the current setup.
> If we have that consensus then fine, we can move things around.

I don't care which way we go (everything in hw/ or split into subdirs), but the current state where some logically depending pieces are in hw/ and others are in hw/foojust plain sucks.

Since you don't have that problem, you can just ignore this patch for arm. It's really a cleanup for me so that I stay sane :).


Alex
Peter Maydell - Jan. 25, 2013, 1:40 p.m.
On 25 January 2013 13:37, Alexander Graf <agraf@suse.de> wrote:
> On 25.01.2013, at 14:33, Peter Maydell wrote:
>> On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 25.01.2013 11:43, schrieb Peter Maydell:
>>> You so far refused to have new SoCs/devices put in hw/arm/. Doing so
>>> does keep consistency but creates more work moving them later.
>>
>> I haven't *refused*. I just haven't seen a consensus about what
>> we want the filesystem layout to be, in the absence of which I
>> haven't seen any great reason to change from the current setup.
>> If we have that consensus then fine, we can move things around.
>
> I don't care which way we go (everything in hw/ or split into
> subdirs), but the current state where some logically depending
> pieces are in hw/ and others are in hw/foo just plain sucks.
>
> Since you don't have that problem, you can just ignore this patch
> for arm. It's really a cleanup for me so that I stay sane :).

Well, I do care, because we should be aiming for some consistency
across architectures, whether we do that by moving more files
into hw/$arch/ or by moving the handful of files and random
Makefile.objs out of hw/$arch/...

If we have some consensus on moving things into hw/$arch that's
fine and we can move the arm stuff in 1.5 sometime I guess.

-- PMM
Andreas Färber - Jan. 25, 2013, 1:50 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 25.01.2013 14:33, schrieb Peter Maydell:
> On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
>> Am 25.01.2013 11:43, schrieb Peter Maydell:
>>> ...so why is a big code movement patch 1.4 material? I would
>>> prefer us to wait for 1.5, and then we have a reasonable chance
>>> of saying "release goal for 1.5 is to have moved all the
>>> arch-specific hw files to their new homes". If we commit this
>>> for 1.4 then at 1.4 release the source tree will be in an odd
>>> halfway statet.
>> 
>> You so far refused to have new SoCs/devices put in hw/arm/. Doing
>> so does keep consistency but creates more work moving them
>> later.
> 
> I haven't *refused*. I just haven't seen a consensus about what we
> want the filesystem layout to be, in the absence of which I haven't
> seen any great reason to change from the current setup. If we have
> that consensus then fine, we can move things around.

Word it "rejected" then. I brought this up months ago for a Samsung
patch shortly after Paolo introduced the directory structure.

For kvm/ we had a lengthy discussion with no clear conclusion that I
remember. ppc then went ahead with e500.

/-F

- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRAo2qAAoJEPou0S0+fgE//OEQAKzmNlab4Pzu/uYDsjFBnTgd
WjrLAECOMeNAkuXToo6QhXcJAepllpHOJr21BblKbMFnza7GRhx4YuBtZvT3FWGA
eM9OOqx1/xwuZVVt47aHekKirpXUR7ffqWVpDNJbOTzrXwkJB/+gxCDVMKi+g5N5
vST4v4J6oGQcoElVwYYMQuHdJFEI9wzQx59gTTXK6J5PUaYu2I4CrCiFo8XObS13
2DQfwwHnixesIeMdEY5ORq290zA8eo5cg6SOyteVEAixc1d3u4tieVwQP6jF42YV
xA06dHjFclF6lCrYK9HKC9Rq/z8BWLTSFbAiMVSggxrUHoG0ppTFe3onULod6kV2
tIeYc3OLqG5OuKDAaHZFlKKtVRVSpVdEqo3Y/FpHcPVkfnxZ9uzS5ZSFrPVDQuw7
cMksxn1npnuuflEbqekGtLn29TWV1S9mhhNAHdjiHOBIABrlJ/+MYp1pgt+wrITZ
PN+X2gSfybwOFE8S+P4f/k0iq+cNASV/kn785UPOsVS+VtXyBaatGbDHFjrU5Ugw
TI6GnpMB7WASq8nt3muEx4NitbKWPHL3YdKAjBsFucj3fmKuQ5EQJ8rSWQ8Gh9a1
kWnyzwL7440OXoSnSDXLnBNjwGh3savSE1KwL8VS4is3ew8yChTck99w7PXuNg6U
lRxulTAmQJLjL8qXN6Zl
=73F0
-----END PGP SIGNATURE-----
Alexander Graf - Jan. 25, 2013, 1:51 p.m.
On 25.01.2013, at 14:40, Peter Maydell wrote:

> On 25 January 2013 13:37, Alexander Graf <agraf@suse.de> wrote:
>> On 25.01.2013, at 14:33, Peter Maydell wrote:
>>> On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 25.01.2013 11:43, schrieb Peter Maydell:
>>>> You so far refused to have new SoCs/devices put in hw/arm/. Doing so
>>>> does keep consistency but creates more work moving them later.
>>> 
>>> I haven't *refused*. I just haven't seen a consensus about what
>>> we want the filesystem layout to be, in the absence of which I
>>> haven't seen any great reason to change from the current setup.
>>> If we have that consensus then fine, we can move things around.
>> 
>> I don't care which way we go (everything in hw/ or split into
>> subdirs), but the current state where some logically depending
>> pieces are in hw/ and others are in hw/foo just plain sucks.
>> 
>> Since you don't have that problem, you can just ignore this patch
>> for arm. It's really a cleanup for me so that I stay sane :).
> 
> Well, I do care, because we should be aiming for some consistency
> across architectures, whether we do that by moving more files
> into hw/$arch/ or by moving the handful of files and random
> Makefile.objs out of hw/$arch/...

Sure, how do we reach that consensus? Call in the quorum of the 13 tribes? :)


Alex
Alexander Graf - Jan. 25, 2013, 1:53 p.m.
On 25.01.2013, at 14:51, Alexander Graf wrote:

> 
> On 25.01.2013, at 14:40, Peter Maydell wrote:
> 
>> On 25 January 2013 13:37, Alexander Graf <agraf@suse.de> wrote:
>>> On 25.01.2013, at 14:33, Peter Maydell wrote:
>>>> On 25 January 2013 12:49, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 25.01.2013 11:43, schrieb Peter Maydell:
>>>>> You so far refused to have new SoCs/devices put in hw/arm/. Doing so
>>>>> does keep consistency but creates more work moving them later.
>>>> 
>>>> I haven't *refused*. I just haven't seen a consensus about what
>>>> we want the filesystem layout to be, in the absence of which I
>>>> haven't seen any great reason to change from the current setup.
>>>> If we have that consensus then fine, we can move things around.
>>> 
>>> I don't care which way we go (everything in hw/ or split into
>>> subdirs), but the current state where some logically depending
>>> pieces are in hw/ and others are in hw/foo just plain sucks.
>>> 
>>> Since you don't have that problem, you can just ignore this patch
>>> for arm. It's really a cleanup for me so that I stay sane :).
>> 
>> Well, I do care, because we should be aiming for some consistency
>> across architectures, whether we do that by moving more files
>> into hw/$arch/ or by moving the handful of files and random
>> Makefile.objs out of hw/$arch/...
> 
> Sure, how do we reach that consensus? Call in the quorum of the 13 tribes? :)

Or in other words: Today every maintainer decides himself. This is why we have hw/pci, hw/dataplane, etc. IMHO architectures are no different than other subtrees.


Alex
Peter Maydell - Jan. 25, 2013, 2:04 p.m.
On 25 January 2013 13:53, Alexander Graf <agraf@suse.de> wrote:
> On 25.01.2013, at 14:51, Alexander Graf wrote:
>> On 25.01.2013, at 14:40, Peter Maydell wrote:
>>> Well, I do care, because we should be aiming for some consistency
>>> across architectures, whether we do that by moving more files
>>> into hw/$arch/ or by moving the handful of files and random
>>> Makefile.objs out of hw/$arch/...
>>
>> Sure, how do we reach that consensus? Call in the quorum of the 13 tribes? :)

We have a mailing list discussion and see if anybody wants
to argue against the subtree approach. Thus far nobody seems
to be arguing against particularly, and so we appear to be
heading towards consensus :-)

-- PMM
Anthony Liguori - Jan. 25, 2013, 2:18 p.m.
Peter Maydell <peter.maydell@linaro.org> writes:

> On 25 January 2013 13:53, Alexander Graf <agraf@suse.de> wrote:
>> On 25.01.2013, at 14:51, Alexander Graf wrote:
>>> On 25.01.2013, at 14:40, Peter Maydell wrote:
>>>> Well, I do care, because we should be aiming for some consistency
>>>> across architectures, whether we do that by moving more files
>>>> into hw/$arch/ or by moving the handful of files and random
>>>> Makefile.objs out of hw/$arch/...
>>>
>>> Sure, how do we reach that consensus? Call in the quorum of the 13 tribes? :)
>
> We have a mailing list discussion and see if anybody wants
> to argue against the subtree approach. Thus far nobody seems
> to be arguing against particularly, and so we appear to be
> heading towards consensus :-)

Previously, subdirs were hard because the build system sucked.  It sucks
less now.  Having a directory of 300 files sucks.

We don't need a grand consensus.  git handles renames very well.  We can
always reorganize later.

Regards,

Anthony Liguori

>
> -- PMM

Patch

diff --git a/hw/cuda.c b/hw/cuda.c
index d59e0ae..bbd1fda 100644
--- a/hw/cuda.c
+++ b/hw/cuda.c
@@ -23,7 +23,7 @@ 
  * THE SOFTWARE.
  */
 #include "hw.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 #include "adb.h"
 #include "qemu/timer.h"
 #include "sysemu/sysemu.h"
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index 9484166..95639d5 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -24,7 +24,7 @@ 
  */
 
 #include "pci/pci_host.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 #include "pci/pci.h"
 
 /* debug Grackle */
diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
index b9ec8e7..c0a71c3 100644
--- a/hw/heathrow_pic.c
+++ b/hw/heathrow_pic.c
@@ -23,7 +23,7 @@ 
  * THE SOFTWARE.
  */
 #include "hw.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 
 /* debug PIC */
 //#define DEBUG_PIC
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index d8f9b4b..e0f04dc 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -22,9 +22,9 @@ 
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
-#include <hw/hw.h>
-#include <hw/ppc_mac.h>
-#include <hw/mac_dbdma.h>
+#include "hw/hw.h"
+#include "hw/ppc/mac.h"
+#include "hw/mac_dbdma.h"
 #include "block/block.h"
 #include "sysemu/dma.h"
 
diff --git a/hw/mac_nvram.c b/hw/mac_nvram.c
index 71093c2..eec7ca4 100644
--- a/hw/mac_nvram.c
+++ b/hw/mac_nvram.c
@@ -25,7 +25,7 @@ 
 #include "hw.h"
 #include "firmware_abi.h"
 #include "sysemu/sysemu.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 
 /* debug NVR */
 //#define DEBUG_NVR
diff --git a/hw/macio.c b/hw/macio.c
index 675a71c..f01fc57 100644
--- a/hw/macio.c
+++ b/hw/macio.c
@@ -23,7 +23,7 @@ 
  * THE SOFTWARE.
  */
 #include "hw.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 #include "pci/pci.h"
 #include "escc.h"
 
diff --git a/hw/openpic.c b/hw/openpic.c
index d414f47..25aa9bf 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -34,7 +34,7 @@ 
  *
  */
 #include "hw.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 #include "pci/pci.h"
 #include "openpic.h"
 #include "sysbus.h"
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index afdcc0e..462146b 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -3,10 +3,6 @@  obj-y = ppc.o ppc_booke.o
 # PREP target
 obj-y += mc146818rtc.o
 obj-y += ppc_prep.o
-# OldWorld PowerMac
-obj-y += ppc_oldworld.o
-# NewWorld PowerMac
-obj-y += ppc_newworld.o
 # IBM pSeries (sPAPR)
 obj-$(CONFIG_PSERIES) += spapr.o spapr_hcall.o spapr_rtas.o spapr_vio.o
 obj-$(CONFIG_PSERIES) += xics.o spapr_vty.o spapr_llan.o spapr_vscsi.o
@@ -28,4 +24,9 @@  obj-y += xilinx_ethlite.o
 
 obj-y := $(addprefix ../,$(obj-y))
 
+# OldWorld PowerMac
+obj-y += mac_oldworld.o
+# NewWorld PowerMac
+obj-y += mac_newworld.o
+# e500
 obj-$(CONFIG_FDT) += e500.o mpc8544ds.o e500plat.o
diff --git a/hw/ppc_mac.h b/hw/ppc/mac.h
similarity index 100%
rename from hw/ppc_mac.h
rename to hw/ppc/mac.h
diff --git a/hw/ppc_newworld.c b/hw/ppc/mac_newworld.c
similarity index 98%
rename from hw/ppc_newworld.c
rename to hw/ppc/mac_newworld.c
index b1973f1..f3c01bf 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -46,28 +46,28 @@ 
  * 0001:05:0c.0 IDE interface [0101]: Broadcom K2 SATA [1166:0240]
  *
  */
-#include "hw.h"
-#include "ppc.h"
-#include "ppc_mac.h"
-#include "adb.h"
-#include "mac_dbdma.h"
-#include "nvram.h"
-#include "pci/pci.h"
+#include "hw/hw.h"
+#include "hw/ppc.h"
+#include "hw/ppc/mac.h"
+#include "hw/adb.h"
+#include "hw/mac_dbdma.h"
+#include "hw/nvram.h"
+#include "hw/pci/pci.h"
 #include "net/net.h"
 #include "sysemu/sysemu.h"
-#include "boards.h"
-#include "fw_cfg.h"
-#include "escc.h"
-#include "openpic.h"
-#include "ide.h"
-#include "loader.h"
+#include "hw/boards.h"
+#include "hw/fw_cfg.h"
+#include "hw/escc.h"
+#include "hw/openpic.h"
+#include "hw/ide.h"
+#include "hw/loader.h"
 #include "elf.h"
 #include "sysemu/kvm.h"
 #include "kvm_ppc.h"
 #include "hw/usb.h"
 #include "sysemu/blockdev.h"
 #include "exec/address-spaces.h"
-#include "sysbus.h"
+#include "hw/sysbus.h"
 
 #define MAX_IDE_BUS 2
 #define CFG_ADDR 0xf0000510
diff --git a/hw/ppc_oldworld.c b/hw/ppc/mac_oldworld.c
similarity index 97%
rename from hw/ppc_oldworld.c
rename to hw/ppc/mac_oldworld.c
index de34e75..dfbfa54 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -23,21 +23,21 @@ 
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
-#include "hw.h"
-#include "ppc.h"
-#include "ppc_mac.h"
-#include "adb.h"
-#include "mac_dbdma.h"
-#include "nvram.h"
+#include "hw/hw.h"
+#include "hw/ppc.h"
+#include "mac.h"
+#include "hw/adb.h"
+#include "hw/mac_dbdma.h"
+#include "hw/nvram.h"
 #include "sysemu/sysemu.h"
 #include "net/net.h"
-#include "isa.h"
-#include "pci/pci.h"
-#include "boards.h"
-#include "fw_cfg.h"
-#include "escc.h"
-#include "ide.h"
-#include "loader.h"
+#include "hw/isa.h"
+#include "hw/pci/pci.h"
+#include "hw/boards.h"
+#include "hw/fw_cfg.h"
+#include "hw/escc.h"
+#include "hw/ide.h"
+#include "hw/loader.h"
 #include "elf.h"
 #include "sysemu/kvm.h"
 #include "kvm_ppc.h"
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 4675792..f1c3c20 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -22,7 +22,7 @@ 
  * THE SOFTWARE.
  */
 #include "hw.h"
-#include "ppc_mac.h"
+#include "ppc/mac.h"
 #include "pci/pci.h"
 #include "pci/pci_host.h"