Proposal for reorg of kernel directory

[Arnd Bergmann]

On Middeweken 22 Juni 2005 21:36, Becky Bruce wrote:
> OK, so let's talk about how the organization of platforms would look if 
> we go with the split.   As I see it, there are several options:
> 
> 1.  Slam all of the platform-specific files into a flat "platforms" 
> directory.

That seems to combine the most pain with the least benefit. Instead
of one heap of stuff you'd have two, with unclear rules of which one
some of the files belong to. E.g. interrupt handling code traditionally
belongs into the kernel directory but is also platform specific.

Moving a file around breaks patches and causes trouble when typing
the old names by habit, so it should only be done if there is

- a real advantage in moving it
- an obvious choice where it belongs
- a low risk of having to move it again

> 2.  Do something similar to the 32-bit tree's implementation of the 
> platforms dir, where single-platform code is at the highest level in 
> "platforms".  Create subdirectories for platforms which are very 
> similar and share most of their code - I believe this ties in with 
> Arnd's idea about more generic platforms.

Besides ppc32, there is no other arch implementing that scheme.
I'd rather name files in the most common way than trying to
mimic ppc32 in order to minimize the surprise level of people
doing infrequent cross-platform development.

> 3.  Subdirs for each platform under the platforms directory.  I don't 
> really like this one, but it is an option.

This is done by h8300, m68knommu and sh, which are all infrequently used
by most kernel hackers.

The most widely used naming scheme would be

4. Have subdirectories directly under arch/ppc64

arch/
     ppc64/
           kernel
           mach-iSeries
           mach-pSeries
           mach-bpa
           ...

We might want to drop the mach- prefix though, since these are
commonly called platforms, not machines, on ppc64.

Also, while we're at it, we should finally get rid of the StudlyCaps
file names like 'ItLpQueue'. Using the capital S in iSeries and
pSeries is probably a good idea, but it can also be dropped as 
a file name prefix if the directory already has the platform name.

My suggestion would be:

# move all pci stuff together, regardless of platform (see i386, mips)
mv arch/ppc64/kernel/pci_iommu.c	arch/ppc64/pci/iommu.c
mv arch/ppc64/kernel/pci_direct_iommu.c	arch/ppc64/pci/direct_iommu.c
mv arch/ppc64/kernel/pci_dn.c		arch/ppc64/pci/prom.c
mv arch/ppc64/kernel/iSeries_pci.c	arch/ppc64/pci/iSeries_pci.c
mv arch/ppc64/kernel/iSeries_pci_reset.c arch/ppc64/pci/iSeries_pci_reset.c
mv arch/ppc64/kernel/pSeries_pci.c	arch/ppc64/pci/pSeries_pci.c
mv arch/ppc64/kernel/maple_pci.c	arch/ppc64/pci/maple_pci.c
mv arch/ppc64/kernel/pmac_pci.c		arch/ppc64/pci/pmac_pci.c

# interrupt related stuff
mv arch/ppc64/kernel/xics.c		arch/ppc64/kernel/irq/xics.c
mv arch/ppc64/kernel/mpic.c		arch/ppc64/kernel/irq/mpic.c
mv arch/ppc64/kernel/bpa_iic.c		arch/ppc64/kernel/irq/bpa_iic.c
mv arch/ppc64/kernel/spider_pic.c	arch/ppc64/kernel/irq/spider_pic.c
mv arch/ppc64/kernel/irq.c		arch/ppc64/kernel/irq/irq.c
mv arch/ppc64/kernel/iSeries_irq.c	arch/ppc64/kernel/irq/iSeries_irq.c

# move ppc32 emulation to a new dir (see x86_64)
mv arch/ppc64/kernel/*32.[chS]		arch/ppc64/ppc32/

# get rtas out of kernel/
mv arch/ppc64/kernel/rtasd.c		arch/ppc64/rtas/rtasd.c
mv arch/ppc64/kernel/rtas_flash.c	arch/ppc64/rtas/flash.c
mv arch/ppc64/kernel/rtas-proc.c	arch/ppc64/rtas/proc.c
mv arch/ppc64/kernel/rtas_pci.c		arch/ppc64/rtas/pci.c

# all iSeries files
mv arch/ppc64/kernel/HvCall.c		arch/ppc64/iSeries/hvcall.c
mv arch/ppc64/kernel/hvCall.S		arch/ppc64/iSeries/hvcall.S
mv arch/ppc64/kernel/HvLpConfig.c	arch/ppc64/iSeries/hv_lpconfig.c
mv arch/ppc64/kernel/HvLpEvent.c	arch/ppc64/iSeries/hv_lpevent.c
mv arch/ppc64/kernel/iSeries_htab.c	arch/ppc64/iSeries/htab.c
mv arch/ppc64/kernel/iSeries_iommu.c	arch/ppc64/iSeries/iommu.c
mv arch/ppc64/kernel/iSeries_proc.c	arch/ppc64/iSeries/proc.c
mv arch/ppc64/kernel/iSeries_setup.c	arch/ppc64/iSeries/setup.c
mv arch/ppc64/kernel/iSeries_setup.h	arch/ppc64/iSeries/setup.h
mv arch/ppc64/kernel/iSeries_smp.c	arch/ppc64/iSeries/smp.c
mv arch/ppc64/kernel/iSeries_VpdInfo.c	arch/ppc64/iSeries/vpdinfo.c
mv arch/ppc64/kernel/ItLpQueue.c	arch/ppc64/iSeries/it_lpqueue.c
mv arch/ppc64/kernel/LparData.c		arch/ppc64/iSeries/lpardata.c
mv arch/ppc64/kernel/mf.c		arch/ppc64/iSeries/mf.c
mv arch/ppc64/kernel/XmPciLpEvent.c	arch/ppc64/iSeries/xm_pci_lpevent.c

# all pSeries files, but leave xics.c in kernel/ (with other interrupt code)
mv arch/ppc64/kernel/ras.c		arch/ppc64/pSeries/ras.c
mv arch/ppc64/kernel/scanlog.c		arch/ppc64/pSeries/scanlog.c
mv arch/ppc64/kernel/eeh.c		arch/ppc64/pSeries/eeh.c
mv arch/ppc64/kernel/hvconsole.c	arch/ppc64/pSeries/hvconsole.c
mv arch/ppc64/kernel/hvcserver.c	arch/ppc64/pSeries/hvcserver.c
mv arch/ppc64/kernel/pSeries_hvCall.S	arch/ppc64/pSeries/hvcall.S
mv arch/ppc64/kernel/pSeries_iommu.c	arch/ppc64/pSeries/iommu.c
mv arch/ppc64/kernel/pSeries_lpar.c	arch/ppc64/pSeries/lpar.c
mv arch/ppc64/kernel/pSeries_nvram.c	arch/ppc64/pSeries/nvram.c
mv arch/ppc64/kernel/pSeries_setup.c	arch/ppc64/pSeries/setup.c
mv arch/ppc64/kernel/pSeries_smp.c	arch/ppc64/pSeries/smp.c

# all pmac files
mv arch/ppc64/kernel/pmac_feature.c	arch/ppc64/pmac/feature.c
mv arch/ppc64/kernel/pmac.h		arch/ppc64/pmac/pmac.h
mv arch/ppc64/kernel/pmac_low_i2c.c	arch/ppc64/pmac/low_i2c.c
mv arch/ppc64/kernel/pmac_nvram.c	arch/ppc64/pmac/nvram.c
mv arch/ppc64/kernel/pmac_setup.c	arch/ppc64/pmac/setup.c
mv arch/ppc64/kernel/pmac_smp.c		arch/ppc64/pmac/smp.c
mv arch/ppc64/kernel/pmac_time.c	arch/ppc64/pmac/time.c

# BPA from the patches I sent today, excluding iic and spider_pic
mv arch/ppc64/kernel/bpa_nvram.c	arch/ppc64/bpa/nvram.c
mv arch/ppc64/kernel/bpa_iommu.c	arch/ppc64/bpa/iommu.c
mv arch/ppc64/kernel/bpa_iommu.h	arch/ppc64/bpa/iommu.h
mv arch/ppc64/kernel/bpa_setup.c	arch/ppc64/bpa/setup.c
mv arch/ppc64/kernel/spu_base.c		arch/ppc64/bpa/spu_base.c

# Not sure about a shared path for maple and future platforms
mv arch/ppc64/kernel/maple_setup.c	arch/ppc64/maple/setup.c
mv arch/ppc64/kernel/maple_time.c	arch/ppc64/maple/time.c

It's always a compromise between binding to the platform or to the
functionality. A different approach would be to group mostly by
functionality, which would probably be irq, iommu, time, smp,
nvram and setup, while putting the remaining platform files into
platform directories.

	Arnd <><