| Message ID | 1359018245-24344-2-git-send-email-afaerber@suse.de |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
-----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-----
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
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
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
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
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"
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%)