I submitted this some time ago and did not get much feedback,
but based on today's IRC discussion want to give it another
shot. The potentially more controversial patches are at the
end, so you can simply apply the more obvious ones.
Please consider for 2.6.23.
Arnd <><
--
Many platforms currently define their own add_bridge function, some
of them globally. This breaks some multiplatform configurations.
Prefixing each of these functions with the platform name avoids
this problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/82xx/mpc82xx_ads.c
===================================================================
@@ -570,7 +570,7 @@ void __init maple_pci_init(void)/* Now setup the HyperTransport host if we found any*/-if(ht&&add_bridge(ht)!=0)+if(ht&&maple_add_bridge(ht)!=0)of_node_put(ht);/*
@@ -35,8 +35,6 @@#define DBG(x...)#endif-staticintadd_bridge(structdevice_node*dev);-/* XXX Could be per-controller, but I don't think we risk anything by*assumingwewon'thavebothUniNorthandBandit*/staticinthas_uninorth;
@@ -1050,7 +1048,7 @@ void __init pmac_pci_init(void)/* Probe HT last as it relies on the agp resources to be already*setup*/-if(ht&&add_bridge(ht)!=0)+if(ht&&pmac_add_bridge(ht)!=0)of_node_put(ht);/*--
The cores used in the MPC82xx/83xx/86xx embedded controllers are very similar
to those in the 32 bit general-purpose processors, so it makes sense to
treat them as the same CPU family.
Choosing between the embedded platforms and the multiplatform code is
now done in the platform menu, but functionally everything stays the
same.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/Kconfig
===================================================================
Currently, PPC64 is a top level configuration option in
arch/powerpc/Kconfig, which is somewhat unconventional.
Moving it into the CPU selection menu is a natural choice,
and is transparent to the rest of the configuration logic.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/Kconfig.cputype
===================================================================
All platforms based on 6xx compatible cores should be able to
coexisting in a single kernel image and do all necessary configuration
based on the device tree.
This moves the missing 8{2,3,6}xx platforms under
CONFIG_PPC_MULTIPLATFORM to make that possible to configure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/82xx/Kconfig
===================================================================
The multiplatform option has become pointless since all
platforms types are multiplatform by definition.
Keep the symbol around in case some code still uses it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/Kconfig
===================================================================
A lot of the options in arch/powerpc/Kconfig deal with the CPU menu,
and my next patches add more to them. Moving them to a new
arch/powerpc/platforms/Kconfig.cputype file makes it easier to
follow.
There are no functional changes in here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
@@ -132,123 +127,6 @@ config PPC64_SWSUSPdepends onPPC64&&(BROKEN||(PPC_PMAC64&&EXPERIMENTAL))defaulty-menu"Processor support"-choice-prompt"Processor Type"-depends onPPC32-default6xx--configCLASSIC32-bool"52xx/6xx/7xx/74xx"-selectPPC_FPU-select6xx-help-TherearefourfamiliesofPowerPCchipssupported.Themorecommon-types(601,603,604,740,750,7400),theMotorolaembedded-versions(821,823,850,855,860,52xx,82xx,83xx),theAMCC-embeddedversions(403and405)andthehighend64bitPower-processors(POWER3,POWER4,andIBMPPC970alsoknownasG5).--Thisoptionisthecatch-allfor6xxtypes,includingsomeofthe-embeddedversions.Unlessthereisseeanoptionforthespecific-chipfamilyyouareusing,youwantthisoption.--Youdonotwantthisifyouarebuildingakernelfora64bit-IBMRS/6000oranAppleG5,choose6xx.--Ifunsure,selectthisoption--Notethatthekernelrunsin32-bitmodeevenon64-bitchips.--configPPC_82xx-bool"Freescale 82xx"-select6xx-selectPPC_FPU--configPPC_83xx-bool"Freescale 83xx"-select6xx-selectFSL_SOC-select83xx-selectPPC_FPU-selectWANT_DEVICE_TREE--configPPC_85xx-bool"Freescale 85xx"-selectE500-selectFSL_SOC-select85xx-selectWANT_DEVICE_TREE--configPPC_86xx-bool"Freescale 86xx"-select6xx-selectFSL_SOC-selectFSL_PCIE-selectPPC_FPU-selectALTIVEC-help-TheFreescaleE600SoCshave74xxcores.--configPPC_8xx-bool"Freescale 8xx"-selectFSL_SOC-select8xx--config40x-bool"AMCC 40x"-selectPPC_DCR_NATIVE--config44x-bool"AMCC 44x"-selectPPC_DCR_NATIVE-selectWANT_DEVICE_TREE--configE200-bool"Freescale e200"--endchoice--configPOWER4_ONLY-bool"Optimize for POWER4"-depends onPPC64-defaultn----help----CausethecompilertooptimizeforPOWER4/POWER5/PPC970processors.-TheresultingbinarywillnotworkonPOWER3orRS64processors-whencompiledwithbinutils2.15orlater.--configPOWER3-bool-depends onPPC64-defaultyif!POWER4_ONLY--configPOWER4-depends onPPC64-def_booly--config6xx-bool--# this is temp to handle compat with arch=ppc-config8xx-bool--# this is temp to handle compat with arch=ppc-config83xx-bool--# this is temp to handle compat with arch=ppc-config85xx-bool--configE500-bool--configPPC_FPU-bool-defaultyifPPC64-configPPC_DCR_NATIVEbooldefaultn
@@ -267,134 +145,6 @@ config PPC_OF_PLATFORM_PCIdepends onPPC64# not supported on 32 bits yetdefaultn-config4xx-bool-depends on40x||44x-defaulty--configBOOKE-bool-depends onE200||E500||44x-defaulty--configFSL_BOOKE-bool-depends onE200||E500-defaulty--configPTE_64BIT-bool-depends on44x||E500-defaultyif44x-defaultyifE500&&PHYS_64BIT--configPHYS_64BIT-bool'Large physical address support'ifE500-depends on44x||E500-selectRESOURCES_64BIT-defaultyif44x----help----Thisoptionenableskernelsupportforlargerthan32-bitphysical-addresses.Thisfeaturesisnotbeavailableonalle500cores.--Ifindoubt,sayNhere.--configALTIVEC-bool"AltiVec Support"-depends onCLASSIC32||POWER4----help----ThisoptionenableskernelsupportfortheAltivecextensionstothe-PowerPCprocessor.Thekernelcurrentlysupportssavingandrestoring-altivecregisters,andturningonthe'altivec enable'bitsouser-processescanexecutealtivecinstructions.--Thisoptionisonlyusefullyifyouhaveaprocessorthatsupports-altivec(G4,otherwiseknownas74xxseries),butdoesnothave-anyaffectonanon-altiveccpu(itdoes,howeveraddcodetothe-kernel).--Ifindoubt,sayYhere.--configSPE-bool"SPE Support"-depends onE200||E500-defaulty----help----ThisoptionenableskernelsupportfortheSignalProcessing-Extensions(SPE)tothePowerPCprocessor.Thekernelcurrently-supportssavingandrestoringSPEregisters,andturningonthe-'spe enable'bitsouserprocessescanexecuteSPEinstructions.--Thisoptionisonlyusefulifyouhaveaprocessorthatsupports-SPE(e500,otherwiseknownas85xxseries),butdoesnothaveany-effectonanon-specpu(itdoes,howeveraddcodetothekernel).--Ifindoubt,sayYhere.--configPPC_STD_MMU-bool-depends on6xx||POWER3||POWER4||PPC64-defaulty--configPPC_STD_MMU_32-def_booly-depends onPPC_STD_MMU&&PPC32--configPPC_MM_SLICES-bool-defaultyifHUGETLB_PAGE-defaultn--configVIRT_CPU_ACCOUNTING-bool"Deterministic task and CPU time accounting"-depends onPPC64-defaulty-help-SelectthisoptiontoenablemoreaccuratetaskandCPUtime-accounting.ThisisdonebyreadingaCPUcounteroneach-kernelentryandexitandontransitionswithinthekernel-betweensystem,softirqandhardirqstate,sothereisa-smallperformanceimpact.Thisalsoenablesaccountingof-stolentimeonlogically-partitionedsystemsrunningon-IBMPOWER5-basedmachines.--Ifindoubt,sayYhere.--configSMP-depends onPPC_STD_MMU-bool"Symmetric multi-processing support"----help----ThisenablessupportforsystemswithmorethanoneCPU.Ifyouhave-asystemwithonlyoneCPU,sayN.Ifyouhaveasystemwithmore-thanoneCPU,sayY.Notethatthekerneldoesnotcurrently-supportSMPmachineswith603/603e/603evorPPC750("G3")processors-sincetheyhaveinadequatehardwaresupportformultiprocessor-operation.--IfyousayNhere,thekernelwillrunonsingleandmultiprocessor-machines,butwilluseonlyoneCPUofamultiprocessormachine.If-yousayYhere,thekernelwillrunonsingle-processormachines.-Onasingle-processormachine,thekernelwillrunfasterifyousay-Nhere.--Ifyoudon'tknowwhattodohere,sayN.--configNR_CPUS-int"Maximum number of CPUs (2-128)"-range2128-depends onSMP-default"32"ifPPC64-default"4"--configNOT_COHERENT_CACHE-bool-depends on4xx||8xx||E200-defaulty--configCONFIG_CHECK_CACHE_COHERENCY-bool-endmenu-source"init/Kconfig"source"arch/powerpc/platforms/Kconfig"
@@ -0,0 +1,252 @@+configPPC64+bool"64-bit kernel"+defaultn+help+Thisoptionselectswhethera32-bitora64-bitkernel+willbebuilt.++menu"Processor support"+choice+prompt"Processor Type"+depends onPPC32+default6xx++configCLASSIC32+bool"52xx/6xx/7xx/74xx"+selectPPC_FPU+select6xx+help+TherearefourfamiliesofPowerPCchipssupported.Themorecommon+types(601,603,604,740,750,7400),theMotorolaembedded+versions(821,823,850,855,860,52xx,82xx,83xx),theAMCC+embeddedversions(403and405)andthehighend64bitPower+processors(POWER3,POWER4,andIBMPPC970alsoknownasG5).++Thisoptionisthecatch-allfor6xxtypes,includingsomeofthe+embeddedversions.Unlessthereisseeanoptionforthespecific+chipfamilyyouareusing,youwantthisoption.++Youdonotwantthisifyouarebuildingakernelfora64bit+IBMRS/6000oranAppleG5,choose6xx.++Ifunsure,selectthisoption++Notethatthekernelrunsin32-bitmodeevenon64-bitchips.++configPPC_82xx+bool"Freescale 82xx"+select6xx+selectPPC_FPU++configPPC_83xx+bool"Freescale 83xx"+select6xx+selectFSL_SOC+select83xx+selectPPC_FPU+selectWANT_DEVICE_TREE++configPPC_85xx+bool"Freescale 85xx"+selectE500+selectFSL_SOC+select85xx+selectWANT_DEVICE_TREE++configPPC_86xx+bool"Freescale 86xx"+select6xx+selectFSL_SOC+selectFSL_PCIE+selectPPC_FPU+selectALTIVEC+help+TheFreescaleE600SoCshave74xxcores.++configPPC_8xx+bool"Freescale 8xx"+selectFSL_SOC+select8xx++config40x+bool"AMCC 40x"+selectPPC_DCR_NATIVE++config44x+bool"AMCC 44x"+selectPPC_DCR_NATIVE+selectWANT_DEVICE_TREE++configE200+bool"Freescale e200"++endchoice++configPOWER4_ONLY+bool"Optimize for POWER4"+depends onPPC64+defaultn+---help---+CausethecompilertooptimizeforPOWER4/POWER5/PPC970processors.+TheresultingbinarywillnotworkonPOWER3orRS64processors+whencompiledwithbinutils2.15orlater.++configPOWER3+bool+depends onPPC64+defaultyif!POWER4_ONLY++configPOWER4+depends onPPC64+def_booly++config6xx+bool++# this is temp to handle compat with arch=ppc+config8xx+bool++# this is temp to handle compat with arch=ppc+config83xx+bool++# this is temp to handle compat with arch=ppc+config85xx+bool++configE500+bool++configPPC_FPU+bool+defaultyifPPC64++config4xx+bool+depends on40x||44x+defaulty++configBOOKE+bool+depends onE200||E500||44x+defaulty++configFSL_BOOKE+bool+depends onE200||E500+defaulty++configPTE_64BIT+bool+depends on44x||E500+defaultyif44x+defaultyifE500&&PHYS_64BIT++configPHYS_64BIT+bool'Large physical address support'ifE500+depends on44x||E500+selectRESOURCES_64BIT+defaultyif44x+---help---+Thisoptionenableskernelsupportforlargerthan32-bitphysical+addresses.Thisfeaturesisnotbeavailableonalle500cores.++Ifindoubt,sayNhere.++configALTIVEC+bool"AltiVec Support"+depends onCLASSIC32||POWER4+---help---+ThisoptionenableskernelsupportfortheAltivecextensionstothe+PowerPCprocessor.Thekernelcurrentlysupportssavingandrestoring+altivecregisters,andturningonthe'altivec enable'bitsouser+processescanexecutealtivecinstructions.++Thisoptionisonlyusefullyifyouhaveaprocessorthatsupports+altivec(G4,otherwiseknownas74xxseries),butdoesnothave+anyaffectonanon-altiveccpu(itdoes,howeveraddcodetothe+kernel).++Ifindoubt,sayYhere.++configSPE+bool"SPE Support"+depends onE200||E500+defaulty+---help---+ThisoptionenableskernelsupportfortheSignalProcessing+Extensions(SPE)tothePowerPCprocessor.Thekernelcurrently+supportssavingandrestoringSPEregisters,andturningonthe+'spe enable'bitsouserprocessescanexecuteSPEinstructions.++Thisoptionisonlyusefulifyouhaveaprocessorthatsupports+SPE(e500,otherwiseknownas85xxseries),butdoesnothaveany+effectonanon-specpu(itdoes,howeveraddcodetothekernel).++Ifindoubt,sayYhere.++configPPC_STD_MMU+bool+depends on6xx||POWER3||POWER4||PPC64+defaulty++configPPC_STD_MMU_32+def_booly+depends onPPC_STD_MMU&&PPC32++configPPC_MM_SLICES+bool+defaultyifHUGETLB_PAGE+defaultn++configVIRT_CPU_ACCOUNTING+bool"Deterministic task and CPU time accounting"+depends onPPC64+defaulty+help+SelectthisoptiontoenablemoreaccuratetaskandCPUtime+accounting.ThisisdonebyreadingaCPUcounteroneach+kernelentryandexitandontransitionswithinthekernel+betweensystem,softirqandhardirqstate,sothereisa+smallperformanceimpact.Thisalsoenablesaccountingof+stolentimeonlogically-partitionedsystemsrunningon+IBMPOWER5-basedmachines.++Ifindoubt,sayYhere.++configSMP+depends onPPC_STD_MMU+bool"Symmetric multi-processing support"+---help---+ThisenablessupportforsystemswithmorethanoneCPU.Ifyouhave+asystemwithonlyoneCPU,sayN.Ifyouhaveasystemwithmore+thanoneCPU,sayY.Notethatthekerneldoesnotcurrently+supportSMPmachineswith603/603e/603evorPPC750("G3")processors+sincetheyhaveinadequatehardwaresupportformultiprocessor+operation.++IfyousayNhere,thekernelwillrunonsingleandmultiprocessor+machines,butwilluseonlyoneCPUofamultiprocessormachine.If+yousayYhere,thekernelwillrunonsingle-processormachines.+Onasingle-processormachine,thekernelwillrunfasterifyousay+Nhere.++Ifyoudon'tknowwhattodohere,sayN.++configNR_CPUS+int"Maximum number of CPUs (2-128)"+range2128+depends onSMP+default"32"ifPPC64+default"4"++configNOT_COHERENT_CACHE+bool+depends on4xx||8xx||E200+defaulty++configCONFIG_CHECK_CACHE_COHERENCY+bool++endmenu--
We can choose the -mcpu= gcc flags for compiling the kernel
based on the platform that we build for. In case of multiplatform
kernels, this chooses a setting for a common subset.
When using a platform type that can use different CPUs, a
new option CONFIG_PPC_CPU_SELECTION can be enabled to select
more specifically which CPUs the kernel will be able to
run on.
This replaces the CONFIG_POWER4_ONLY option with an much more
generic approach.
Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible
to select a CPU to tune for by means of the -mtune= option.
I tried to be very careful when coding the specific rules into
the Kconfig language, but it would be good to have a few
people sanity-checking them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/4xx/Kconfig
===================================================================
@@ -87,6 +87,7 @@ endmenu# 40x specific CPU modules, selected based on the board above.configNP405Hbool+selectCPU_405#depends on ASH# OAK doesn't exist but wanted to keep this around for any future 403GCX boards
@@ -94,6 +95,7 @@ config 403GCXbool#depends on OAKselectIBM405_ERR51+selectCPU_403config405GPbool
@@ -102,19 +104,23 @@ config 405GPconfig405EPbool+selectCPU_405config405GPRbool+selectCPU_405configVIRTEX_II_PROboolselectIBM405_ERR77selectIBM405_ERR51+selectCPU_405configSTB03xxxboolselectIBM405_ERR77selectIBM405_ERR51+selectCPU_405# 40x errata/workaround config symbols, selected by the CPU models above
@@ -168,20 +174,25 @@ config 440EPboolselectPPC_FPUselectIBM440EP_ERR42+selectCPU_440config440GPboolselectIBM_NEW_EMAC_ZMII+selectCPU_440config440GXbool+selectCPU_440config440SPbool+selectCPU_440config440Abooldepends on440GX+selectCPU_440defaulty# 44x errata/workaround config symbols, selected by the CPU models above
@@ -78,24 +78,23 @@ LINUXINCLUDE += $(LINUXINCLUDE-y)CHECKFLAGS+=-m$(SZ)-D__powerpc__-D__powerpc$(SZ)__+OPTFLAGS:=$(callcc-option,$(CONFIG_PPC_MCPU))$(callcc-option,$(CONFIG_PPC_MTUNE))++# compilers older than 4.0.0 can only set -maltivec in 64 bit mode+# when compiling for 970ifeq ($(CONFIG_PPC64),y)GCC_BROKEN_VEC:=$(shellif[$(callcc-version)-lt0400];thenecho"y";fi)-ifeq ($(CONFIG_POWER4_ONLY),y)ifeq ($(CONFIG_ALTIVEC),y)ifeq ($(GCC_BROKEN_VEC),y)-CFLAGS+=$(callcc-option,-mcpu=970)-else-CFLAGS+=$(callcc-option,-mcpu=power4)+OPTFLAGS:=$(callcc-option,-mcpu=970)$(callcc-option,$(CONFIG_PPC_MTUNE))endif-else-CFLAGS+=$(callcc-option,-mcpu=power4)endif-else-CFLAGS+=$(callcc-option,-mtune=power4)endifendif+CFLAGS+=$(OPTFLAGS)+# No AltiVec instruction when building kernelCFLAGS+=$(callcc-option,-mno-altivec)
@@ -107,10 +106,6 @@ CFLAGS += $(call cc-option,-funit-at-a-t# often slow when they are implemented at allCFLAGS+=-mno-string-ifeq ($(CONFIG_6xx),y)-CFLAGS+=-mcpu=powerpc-endif-cpu-as-$(CONFIG_4xx)+=-Wa,-m405cpu-as-$(CONFIG_6xx)+=-Wa,-maltiveccpu-as-$(CONFIG_POWER4)+=-Wa,-maltivec
The existing embedded 6xx platforms will happily coexist
with each other in a single kernel if you let them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linux-2.6/arch/powerpc/platforms/Kconfig
===================================================================
Efika and Lite5200 can both coexist with other 6xx compatible
configurations, so change the Kconfig allow selecting both
at the same time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/52xx/Kconfig
===================================================================
The various e500 platforms can be built in a single kernel,
as long as a small conflict in the header files is resolved.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/85xx/Kconfig
===================================================================
From: Stephen Rothwell <hidden> Date: 2007-06-12 04:11:15
On Tue, 12 Jun 2007 01:28:28 +0200 arnd@arndb.de wrote:
quoted hunk
Many platforms currently define their own add_bridge function, some
of them globally. This breaks some multiplatform configurations.
Prefixing each of these functions with the platform name avoids
this problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/82xx/mpc82xx_ads.c
===================================================================
This is a separate fix and so should be a separate patch. You might also
consider putting that include file in include/asm-powerpc...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <hidden> Date: 2007-06-12 04:15:25
On Tue, 12 Jun 2007 01:28:30 +0200 arnd@arndb.de wrote:
quoted hunk
The existing embedded 6xx platforms will happily coexist
with each other in a single kernel if you let them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
From: Kumar Gala <hidden> Date: 2007-06-12 05:59:34
On Jun 11, 2007, at 6:28 PM, arnd@arndb.de wrote:
quoted hunk
The existing embedded 6xx platforms will happily coexist
with each other in a single kernel if you let them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linux-2.6/arch/powerpc/platforms/Kconfig
===================================================================
From: Paul Mackerras <hidden> Date: 2007-06-12 06:33:37
arnd@arndb.de writes:
Currently, PPC64 is a top level configuration option in
arch/powerpc/Kconfig, which is somewhat unconventional.
It makes a lot of sense to me to have 32 vs. 64 bits as a high level
binary selector that conditions the things that follow. I don't think
it makes sense to push it down into the CPU selection menu.
Paul.
I don't know. As far as I can tell, (BROKEN||BROKEN_ON_SMP) is the
same as simply BROKEN_ON_SMP, which makes the option only show
up when SMP is disabled.
My patch doesn't change that behaviour, I just moved the dependency
down to the individual boards.
Arnd <><
Currently, PPC64 is a top level configuration option in
arch/powerpc/Kconfig, which is somewhat unconventional.
=20
It makes a lot of sense to me to have 32 vs. 64 bits as a high level
binary selector that conditions the things that follow. =A0I don't think
it makes sense to push it down into the CPU selection menu.
Can you eleborate, other than stating the exact opposite of what
my comment said?
I don't mind removing this patch from the series, but I'd like to
understand the reason. I've always thought of the top-level option
as a temporary ugly hack that should eventually go away ;-)
Other than subjective feelings, my reasons for this patch were:
* No other architecture I have seen uses bool options in the top-level
menu, so it would be more consistant to move it to the cpu type
selection menu.
* we have six (depending on how you count) PPC CPU families
supported by Linux (4xx, 6xx, 8xx, e200, e500, ppc64), each
of them incompatible with the others, meaning that you can run
common user space but not a common kernel. Having the list in
as the first Kconfig choice seems logical to me, because
all other options more or less depend on these.
* The only major difference between ppc64 and the others is the
object format of the kernel binary. My impression when playing
with the cpu selection menu was that we have a lot more stuff
depending on 6xx than on ppc64.
* Given the choice between the equivalent
I find the latter easier to understand regarding further options
depending on each of them in the individual platforms, e.g. each
of the platforms/foo/Kconfig files depends on exactly one of these
six options.=20
Arnd <><
From: Paul Mackerras <hidden> Date: 2007-06-12 11:11:20
Arnd Bergmann writes:
Can you eleborate, other than stating the exact opposite of what
my comment said?
It's mostly subjective, I guess. None of the reasons you've cited
seem at all compelling to me, and if we change this stuff then we'll
all get unnecessary questions next time we make a kernel. Anyway I
like it the way it is, and I'm the maintainer. :)
* The only major difference between ppc64 and the others is the
object format of the kernel binary.
I disagree with that. There are major differences at the
implementation level for a lot of things.
Paul.
* The only major difference between ppc64 and the others is the
object format of the kernel binary.
I disagree with that. There are major differences at the
implementation level for a lot of things.
It would be good to converge the 32- and 64-bit implementations,
and/or allow a single kernel image to work on both 32-bit and
64-bit systems, The current situation is far removed from that,
so this patch is a bit premature in that aspect.
Segher
It's mostly subjective, I guess. =A0None of the reasons you've cited
seem at all compelling to me, and if we change this stuff then we'll
all get unnecessary questions next time we make a kernel. =A0Anyway I
like it the way it is, and I'm the maintainer.=20
Ok, fair enough. At least that means I didn't miss an obvious point.
I'll follow up with an updated patch set when no more comments about
the other patches come in.
Arnd <><
=A0 On Tue, 12 Jun 2007 01:28:25 +0200 arnd@arndb.de wrote:
quoted
-config VIRT_CPU_ACCOUNTING
-=A0=A0=A0=A0=A0bool "Deterministic task and CPU time accounting"
=20
I am not sure that this belongs with all the rest.
=20
It's selected by arch/powerpc/platforms/embedded6xx/Kconfig.
=20
Where? =A0I don't see it. =A0VIRT_CPU_ACCOUNTING is a 64-bit only option,
at least until someone implements it for 32-bit.
Sorry, I was confusing this with CONFIG_CHECK_CACHE_COHERENCY for
some weird reason.
My patch moves the entire CPU selection menu to a new file, without
changing any of the contents. If you like, I can add another
patch that moves VIRT_CPU_ACCOUNTING into the platform support or
the general setup menu.
Arnd <><
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-06-12 21:32:33
On Tue, 2007-06-12 at 13:35 +0200, Segher Boessenkool wrote:
and/or allow a single kernel image to work on both 32-bit and
64-bit systems, The current situation is far removed from that,
so this patch is a bit premature in that aspect.
From: Paul Mackerras <hidden> Date: 2007-06-13 00:42:43
Segher Boessenkool writes:
It would be good to converge the 32- and 64-bit implementations,
and/or allow a single kernel image to work on both 32-bit and
64-bit systems, The current situation is far removed from that,
so this patch is a bit premature in that aspect.
There will always be differences in emphasis and focus between 32-bit
and 64-bit. For example, the vast majority of 32-bit systems are UP,
with a few 2-way SMP systems, an insignificant number of 4-way
systems, and nothing bigger than 4-way. In contrast, most 64-bit
machines are SMP, with enough large SMP machines (64-way and bigger)
to be worth worrying about. Hence the 64-bit code focuses on SMP
scalability whereas the 32-bit code focuses on performance for UP and
2-way systems - which is why the hash table invalidations get batched
up on 64-bit machines but not on 32-bit machines, for instance.
Similarly, 64-bit supports large memory (>4GB) and NUMA machines,
whereas 32-bit doesn't.
Paul.
and/or allow a single kernel image to work on both 32-bit and
64-bit systems, The current situation is far removed from that,
so this patch is a bit premature in that aspect.
It would be good to converge the 32- and 64-bit implementations,
and/or allow a single kernel image to work on both 32-bit and
64-bit systems, The current situation is far removed from that,
so this patch is a bit premature in that aspect.
There will always be differences in emphasis and focus between 32-bit
and 64-bit. For example, the vast majority of 32-bit systems are UP,
with a few 2-way SMP systems, an insignificant number of 4-way
systems, and nothing bigger than 4-way. In contrast, most 64-bit
machines are SMP, with enough large SMP machines (64-way and bigger)
to be worth worrying about. Hence the 64-bit code focuses on SMP
scalability whereas the 32-bit code focuses on performance for UP and
2-way systems - which is why the hash table invalidations get batched
up on 64-bit machines but not on 32-bit machines, for instance.
Similarly, 64-bit supports large memory (>4GB) and NUMA machines,
whereas 32-bit doesn't.
While all this is certainly true, there still are many
differences between 32-bit and 64-bit that aren't really
warranted. Also, things like the scalability "knobs"
should perhaps not be directly keyed of the PPC64 symbol.
Anyway, nothing to worry about now I guess ;-)
Segher