Am 25.01.2013 11:43, schrieb Peter Maydell: > On 24 January 2013 09:03, Andreas Färber <afaer...@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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
