Hi!
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
[ ] Willing [ ] Not willing
:-)
-of
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
Hi!
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
Where are these patches?
josh
On 05/11/2007 12:34 PM, Josh Boyer wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
Hi!
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
Where are these patches?
Please find attached my current cvs diff. The Makefile.config part should be fixed better - I know, but had no time yet...
I also attached the patch mentioned in the diff and the config that I currently use.
I have no SMP support at the moment, as I don't have a smp capable machine.
I don't know if it will build correctly, havn't yet finished my build - but I had a few tries already and today fixed - hopefully - the last build error.
I'm also not sure if the kernel will boot fine.
I'm just trying to get the first patches in devel, so if you update something in cvs, it's easier to merge with what I have...
At the moment I'm not *fixing* things. I just try to build a kernel with make alpha directly in my cvs checkout. If it fails, I check where it fails and disable the appropriate module in my alpha config. I will go through the ifnarch's after I finally managed to boot up the new kernel and see that it works. Where appropriate, I will work with kernel upstream to fix the problems - of course...
I'd really like to work together with the current kernel maintainers to provide a kernel spec/srpm, that builds on alpha.
-of
On 05/11/2007 01:51 PM, David Woodhouse wrote:
On Fri, 2007-05-11 at 13:24 +0200, Oliver Falk wrote:
Please find attached my current cvs diff. The Makefile.config part should be fixed better - I know, but had no time yet...
echo 'diff -up' >> ~/.cvsrc
I have no idea where you're putting those ifarches.
Sure. Sorry.
New diff attached.
-of
On Fri, 2007-05-11 at 13:57 +0200, Oliver Falk wrote:
? kernel-2.6.21-alpha.config.new ? linux-2.6-no_fec_for_alpha.patch ? configs/ALPHA ? configs/config-alpha Index: Makefile.config =================================================================== RCS file: /cvs/dist/devel/kernel/Makefile.config,v retrieving revision 1.53 diff -u -p -r1.53 Makefile.config --- Makefile.config 7 Mar 2007 07:25:46 -0000 1.53 +++ Makefile.config 11 May 2007 11:56:31 -0000 @@ -14,9 +14,10 @@ CONFIGFILES = \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ $(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.config \ $(CFG)-i686-xen.config $(CFG)-x86_64-xen.config \
$(CFG)-ia64-xen.config
$(CFG)-ia64-xen.config \
$(CFG)-alpha.config
-PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390 ia64 # sparc sparc64 +PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390 ia64 alpha # sparc sparc64
alpha likely needs to be behind the '#' like sparc is.
josh
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
Can you explain each ifarch? And show Patch701? Why at the end?
Once upon a time the folks at HP were threatening to send me SMP Alpha boxen -- not sure if I could still pull that off...
Index: kernel-2.6.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3148 diff -u -r1.3148 kernel-2.6.spec --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 @@ -167,6 +167,16 @@ %define usesparse 0 %endif
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 +%define with_smp 0 +%define with_pae 0 +%define with_xen 0 +%define with_kdump 0 +%define with_debug 0 +%define usesparse 0 +%define with_modsign 0 +%endif + # Per-arch tweaks
%ifarch %{all_x86} @@ -238,6 +248,13 @@ %define xen_image vmlinux.gz %endif
+%ifarch alpha alphaev6 alphaev67 +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config +%define image_install_path boot +%define make_target boot +%define kernel_image vmlinux +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp %if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config + Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic @@ -452,6 +472,9 @@
# 600 - 699 sparc(64)
+# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch + # # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif %patch11 -p1
# Power management fixes @@ -1106,7 +1131,9 @@ %patch800 -p1
# Exec shield +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch810 -p1 +%endif
# # GPG signed kernel modules @@ -1181,7 +1208,9 @@ %patch1018 -p1 %patch1019 -p1 %patch1020 -p1 +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch1021 -p1 +%endif %patch1022 -p1 %if %{includexen} %patch1023 -p1 @@ -1198,7 +1227,9 @@ # # /dev/crash driver for the crashdump analysis tool # +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1060 -p1 +%endif %if %{includexen} %patch1061 -p1 %endif @@ -1258,7 +1289,9 @@ # DVB spinlock bug %patch1700 -p1 # setuid /proc/self/maps fix. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1720 -p1 +%endif # Add a safety net to softlockup so that it doesn't prevent installs. %patch1740 -p1 # Speed up spinlock debug. @@ -1346,7 +1379,9 @@ #
# Pull in the new firewire stack +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch5000 -p1 +%endif
# # final stuff @@ -1360,6 +1395,9 @@ %patch10002 -p1 %patch10003 -p1
+# alpha related, but must be done at the end... +%patch701 -p0 + # END OF PATCH APPLICATIONS
cp %{SOURCE10} Documentation/
On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote:
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
Can you explain each ifarch? And show Patch701? Why at the end?
Once upon a time the folks at HP were threatening to send me SMP Alpha boxen -- not sure if I could still pull that off...
Index: kernel-2.6.spec
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3148 diff -u -r1.3148 kernel-2.6.spec --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 @@ -167,6 +167,16 @@ %define usesparse 0 %endif
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67
instead of listing all the alpha arches everywhere, you should define a macro like %{all_alpha}
# To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp
Shouldn't need to muck with Release
%if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config
Do you need an alpha-smp.config since you turned smp builds off?
+# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch
Where's this?
# # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif
Is utrace really broken on alpha?
# Exec shield +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch810 -p1 +%endif
# # GPG signed kernel modules @@ -1181,7 +1208,9 @@ %patch1018 -p1 %patch1019 -p1 %patch1020 -p1 +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch1021 -p1 +%endif
Does this patch not apply, or doesn't work, or?
%patch1022 -p1 %if %{includexen} %patch1023 -p1 @@ -1198,7 +1227,9 @@ # # /dev/crash driver for the crashdump analysis tool # +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1060 -p1 +%endif
Same thing here
%if %{includexen} %patch1061 -p1 %endif @@ -1258,7 +1289,9 @@ # DVB spinlock bug %patch1700 -p1 # setuid /proc/self/maps fix. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1720 -p1 +%endif # Add a safety net to softlockup so that it doesn't prevent installs. %patch1740 -p1 # Speed up spinlock debug. @@ -1346,7 +1379,9 @@ #
# Pull in the new firewire stack +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch5000 -p1 +%endif
Same thing here
josh
Josh Boyer wrote:
On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote:
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
+1 for not happy about all the ifdef alpha's
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67
instead of listing all the alpha arches everywhere, you should define a macro like %{all_alpha}
+1
# To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp
Shouldn't need to muck with Release
Indeed. There's a %buildid define further up in the spec if you really want to alter the release tag for your own build, but we're certainly not going to merge this part of the patch. :)
%if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config
Do you need an alpha-smp.config since you turned smp builds off?
Not to mention that they should have different SourceX numbers if you do intend to include both.
On 05/11/2007 03:15 PM, Jarod Wilson wrote:
Josh Boyer wrote:
On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote:
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
+1 for not happy about all the ifdef alpha's
For me it was the fastest and easiest method to actually *build* a newer kernel from this spec. I would be very happy if we can fix it - sure!
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67
instead of listing all the alpha arches everywhere, you should define a macro like %{all_alpha}
+1
Sure. Yes. Not much work.
# To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp
Shouldn't need to muck with Release
Indeed. There's a %buildid define further up in the spec if you really want to alter the release tag for your own build, but we're certainly not going to merge this part of the patch. :)
Yes guys, I know. Sorry, shouldn't have added this hunk. :-)
%if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config
Do you need an alpha-smp.config since you turned smp builds off?
Not to mention that they should have different SourceX numbers if you do intend to include both.
That's true. Typo :-)
-of
On 05/11/2007 02:03 PM, Josh Boyer wrote: [ ... ]
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67
instead of listing all the alpha arches everywhere, you should define a macro like %{all_alpha}
Sure. Go with it.
[ ... ]
+# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch
Where's this?
See my other mail.
# # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif
Is utrace really broken on alpha?
As already stated. I can build it without the ifnarch and send you the error - will take a while of course. My DS10 is quite fast, but not *very* fast...
[ ... ]
See also the notes from my previous mail.
-of
On 05/11/2007 02:01 PM, David Woodhouse wrote:
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
k. ack.
Can you explain each ifarch? And show Patch701? Why at the end?
will do so.
Once upon a time the folks at HP were threatening to send me SMP Alpha boxen -- not sure if I could still pull that off...
give 'em my address :-)
I'll try to provide you with all details within the next few days. Maybe on Monday, soonest... I'm not sure. For me weekend starts now. :-)
Best, Oliver
Index: kernel-2.6.spec
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3148 diff -u -r1.3148 kernel-2.6.spec --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 @@ -167,6 +167,16 @@ %define usesparse 0 %endif
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 +%define with_smp 0 +%define with_pae 0 +%define with_xen 0 +%define with_kdump 0 +%define with_debug 0 +%define usesparse 0 +%define with_modsign 0 +%endif
# Per-arch tweaks
%ifarch %{all_x86} @@ -238,6 +248,13 @@ %define xen_image vmlinux.gz %endif
+%ifarch alpha alphaev6 alphaev67 +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config +%define image_install_path boot +%define make_target boot +%define kernel_image vmlinux +%endif
# To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp %if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config
Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic @@ -452,6 +472,9 @@
# 600 - 699 sparc(64)
+# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch
# # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif %patch11 -p1
# Power management fixes @@ -1106,7 +1131,9 @@ %patch800 -p1
# Exec shield +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch810 -p1 +%endif
# # GPG signed kernel modules @@ -1181,7 +1208,9 @@ %patch1018 -p1 %patch1019 -p1 %patch1020 -p1 +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch1021 -p1 +%endif %patch1022 -p1 %if %{includexen} %patch1023 -p1 @@ -1198,7 +1227,9 @@ # # /dev/crash driver for the crashdump analysis tool # +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1060 -p1 +%endif %if %{includexen} %patch1061 -p1 %endif @@ -1258,7 +1289,9 @@ # DVB spinlock bug %patch1700 -p1 # setuid /proc/self/maps fix. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1720 -p1 +%endif # Add a safety net to softlockup so that it doesn't prevent installs. %patch1740 -p1 # Speed up spinlock debug. @@ -1346,7 +1379,9 @@ #
# Pull in the new firewire stack +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch5000 -p1 +%endif
# # final stuff @@ -1360,6 +1395,9 @@ %patch10002 -p1 %patch10003 -p1
+# alpha related, but must be done at the end... +%patch701 -p0
# END OF PATCH APPLICATIONS
cp %{SOURCE10} Documentation/
On 05/11/2007 02:01 PM, David Woodhouse wrote:
Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc.
OK. If you enable alpha and apply the patches that are really needed, I can build it and tell you where and how it breaks then.
Can you explain each ifarch?
Sure.
And show Patch701? Why at the end?
--- drivers/net/Kconfig.no_fec_mpc52xx_for_alpha.patch 2007-05-03 14:18:50.000000000 +0200 +++ drivers/net/Kconfig 2007-05-03 14:18:55.000000000 +0200 @@ -1889,7 +1889,6 @@ controller on the Renesas H8/300 processor.
source "drivers/net/fec_8xx/Kconfig" -source "drivers/net/fec_mpc52xx/Kconfig" source "drivers/net/fs_enet/Kconfig"
endmenu
linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via config as far as I can remember; So I had to patch it out at the end...
Once upon a time the folks at HP were threatening to send me SMP Alpha boxen -- not sure if I could still pull that off...
Anyone from HP here? Jay, do you have any good contacts?
Index: kernel-2.6.spec
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3148 diff -u -r1.3148 kernel-2.6.spec --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 @@ -167,6 +167,16 @@ %define usesparse 0 %endif
+%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 +%define with_smp 0 +%define with_pae 0 +%define with_xen 0 +%define with_kdump 0 +%define with_debug 0 +%define usesparse 0 +%define with_modsign 0 +%endif
This part is needed for sure. We will enable SMP after the normal up kernel compiles fine and I found someone with a smp-capable box who can do the testing.
# Per-arch tweaks
%ifarch %{all_x86} @@ -238,6 +248,13 @@ %define xen_image vmlinux.gz %endif
+%ifarch alpha alphaev6 alphaev67 +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config +%define image_install_path boot +%define make_target boot +%define kernel_image vmlinux +%endif
Also quite clear I think.
# To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp
Of course we do not need this. It's just because I intentionally wanted to build an new kernel for AlphaCore and we have the convention to add axp to the release, so people know, it's coming from Fedora, but is modified for AC.
%if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config
+Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config
I don't have a smp config at the moment. So we need to put this out, else up will no build clean.
Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic @@ -452,6 +472,9 @@
# 600 - 699 sparc(64)
+# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch
See above notes.
# # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif %patch11 -p1
Compile errors.
# Power management fixes @@ -1106,7 +1131,9 @@ %patch800 -p1
# Exec shield +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch810 -p1 +%endif
Even more compile errors. :-)
# # GPG signed kernel modules @@ -1181,7 +1208,9 @@ %patch1018 -p1 %patch1019 -p1 %patch1020 -p1 +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch1021 -p1 +%endif
Don't remember why. Must have been a compile error as well.
%patch1022 -p1 %if %{includexen} %patch1023 -p1 @@ -1198,7 +1227,9 @@ # # /dev/crash driver for the crashdump analysis tool # +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1060 -p1 +%endif
Compile error.
%if %{includexen} %patch1061 -p1 %endif @@ -1258,7 +1289,9 @@ # DVB spinlock bug %patch1700 -p1 # setuid /proc/self/maps fix. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1720 -p1 +%endif
Compile error.
# Add a safety net to softlockup so that it doesn't prevent installs. %patch1740 -p1 # Speed up spinlock debug. @@ -1346,7 +1379,9 @@ #
# Pull in the new firewire stack +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch5000 -p1 +%endif
Compile error.
# # final stuff @@ -1360,6 +1395,9 @@ %patch10002 -p1 %patch10003 -p1
+# alpha related, but must be done at the end... +%patch701 -p0
# END OF PATCH APPLICATIONS
See above note.
There are not *many* ifnarchs at the moment, but it makes the kernel compile for alpha. Last run was successful, but packaging was a problem because smp config is missing...
Best, Oliver
On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote:
source "drivers/net/fec_8xx/Kconfig" -source "drivers/net/fec_mpc52xx/Kconfig" source "drivers/net/fs_enet/Kconfig"
endmenu
linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via config as far as I can remember; So I had to patch it out at the end...
That's weird -- it doesn't affect any other architectures. Sure you're not defining PPC_MPC52xx? :)
On 05/14/2007 05:30 PM, David Woodhouse wrote:
On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote:
source "drivers/net/fec_8xx/Kconfig" -source "drivers/net/fec_mpc52xx/Kconfig" source "drivers/net/fs_enet/Kconfig"
endmenu
linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via config as far as I can remember; So I had to patch it out at the end...
That's weird -- it doesn't affect any other architectures. Sure you're not defining PPC_MPC52xx? :)
Hm... Would wonder... However; Will try to rebuild without the patch - maybe something was weird at my end... No, it's not defined! ;-)
-of
On 05/14/2007 05:35 PM, Oliver Falk wrote:
On 05/14/2007 05:30 PM, David Woodhouse wrote:
On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote:
source "drivers/net/fec_8xx/Kconfig" -source "drivers/net/fec_mpc52xx/Kconfig" source "drivers/net/fs_enet/Kconfig"
endmenu
linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via config as far as I can remember; So I had to patch it out at the end...
That's weird -- it doesn't affect any other architectures. Sure you're not defining PPC_MPC52xx? :)
Hm... Would wonder... However; Will try to rebuild without the patch - maybe something was weird at my end... No, it's not defined! ;-)
Ah... That's why: + make -s ARCH=alpha nonint_oldconfig drivers/net/fec_mpc52xx/Kconfig:14:warning: leading whitespace ignored drivers/net/fec_mpc52xx/Kconfig:7:warning: 'select' used by config symbol 'FEC_MPC52xx' refer to undefined symbol 'PPC_BESTCOMM' + make -s ARCH=alpha -j2 boot drivers/net/fec_mpc52xx/Kconfig:14:warning: leading whitespace ignored drivers/net/fec_mpc52xx/Kconfig:7:warning: 'select' used by config symbol 'FEC_MPC52xx' refer to undefined symbol 'PPC_BESTCOMM'
Let's see if it compiles...
-of
You seem to build for a bunch of different architectures, but don't have separate config files for most of them.
I'd suggest building for ev4|up, ev56+|up and ev56+|smp. Are there SMP boxen without BWX?
On 05/11/2007 02:13 PM, David Woodhouse wrote:
You seem to build for a bunch of different architectures, but don't have separate config files for most of them.
Good point; Good idea!
I'd suggest building for ev4|up, ev56+|up and ev56+|smp.
No ev4, we disable ev in glibc for example. So no need to build a kernel for it.
We shouldn't forget ev6 and ev67, there should be a lot of them out there. I don't know about ev7, ev7z and the ev68. I think one or the other es45 (ev68) should be also out there...
Also a good question. For x86, we don't build extra SMP capable kernels anymore, true? Maybe we should do this here as well!? SMP wasn't also working stable on alpha. But if it does now, maybe we should enable it by default...
Are there SMP boxen without BWX?
Hm. Maybe someone with more knowledge about h/w can answer this; EV5 afaik doesn't have bwx. And there's the AS1200; SMP capable and with a 21164 processor, maybe ev5, maybe already ev56 (ev5 was only <= 366 MHz and AS1200 has >= 400 Mhz.).
If all this is true :-) I'm sure there's someone who can answer this better...
-of
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
Yeah, I'm not averse to babysitting this -- and when I get home in a fortnight or so I can possibly even dig out the SX164 too.
Got a ppc{64,}>alpha crosscompiler? :)
We could _really_ do with kickstarting the cross-binutils and cross-gcc efforts -- at least for Fedora architectures to start with, and the embedded targets could follow.
On 05/11/2007 01:49 PM, David Woodhouse wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
I know, we don't like ifarchs, but for now it's the easiest way. We apply patches that will need much rework to don't break alpha - I believe...
Of course, I will try to get 'em out as good as I can!
Yeah, I'm not averse to babysitting this -- and when I get home in a fortnight or so I can possibly even dig out the SX164 too.
Oh, great! That's fine to hear!
Got a ppc{64,}>alpha crosscompiler? :)
Nop. :-(
We could _really_ do with kickstarting the cross-binutils and cross-gcc efforts -- at least for Fedora architectures to start with, and the embedded targets could follow.
:-)
-of
On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
The utrace patch is the biggest concern here, really. Not that it's bad code, but its a significant divergence from upstream, and it doesn't work on sparc32 (and presumably, alpha). Aurora is %ifarch conditionalizing that patch (and one later patch that has to be modified slightly for the old ptrace behavior) in our kernels as well.
~spot
On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
The utrace patch is the biggest concern here, really. Not that it's bad code, but its a significant divergence from upstream, and it doesn't work on sparc32 (and presumably, alpha). Aurora is %ifarch conditionalizing that patch (and one later patch that has to be modified slightly for the old ptrace behavior) in our kernels as well.
Does it apply? Seems there's a config option for it... you could just leave that disabled in your .configs.
josh
On Fri, May 11, 2007 at 10:13:21AM -0500, Josh Boyer wrote:
On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
The utrace patch is the biggest concern here, really. Not that it's bad code, but its a significant divergence from upstream, and it doesn't work on sparc32 (and presumably, alpha). Aurora is %ifarch conditionalizing that patch (and one later patch that has to be modified slightly for the old ptrace behavior) in our kernels as well.
Does it apply? Seems there's a config option for it... you could just leave that disabled in your .configs.
Problem is (AIUI) that doing that would remove ptrace functionality completely. With the patch applied, ptrace is implemented as a 'personality' of utrace.
Dave
Indeed utrace does not have an alpha port, and this is necessary to keep the ptrace interface working. rth did some work on one and maybe he'd like to revive it and have you give it a whirl.
Thanks, Roland
On 05/11/2007 05:42 PM, Dave Jones wrote:
On Fri, May 11, 2007 at 10:13:21AM -0500, Josh Boyer wrote:
On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote:
On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote:
A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec?
No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs...
We don't like ifarches. Why?
The utrace patch is the biggest concern here, really. Not that it's bad code, but its a significant divergence from upstream, and it doesn't work on sparc32 (and presumably, alpha). Aurora is %ifarch conditionalizing that patch (and one later patch that has to be modified slightly for the old ptrace behavior) in our kernels as well.
Does it apply? Seems there's a config option for it... you could just leave that disabled in your .configs.
Problem is (AIUI) that doing that would remove ptrace functionality completely. With the patch applied, ptrace is implemented as a 'personality' of utrace.
So. If it doesn't work for sparc32 and we cannot simply disable it via .config, we should stick with ifnarch-ing it for now /me thinks. Maybe some good kernel-hacker can have a look into it.
Working out a patch, so we can disable utrace by .config and automatically enabling ptrace would be the best way!?
-of
On Fri, 11 May 2007 12:49:17 +0100, David Woodhouse dwmw2@infradead.org wrote:
We don't like ifarches. Why?
Mostly because rpmbuild -bp is often useful to run on a different arch. At least this was my reason. They also make the spec crufty if they start to proliferate.
-- Pete
On Fri, 2007-05-11 at 22:49 -0700, Pete Zaitcev wrote:
On Fri, 11 May 2007 12:49:17 +0100, David Woodhouse dwmw2@infradead.org wrote:
We don't like ifarches. Why?
Mostly because rpmbuild -bp is often useful to run on a different arch. At least this was my reason. They also make the spec crufty if they start to proliferate.
Sorry. I was asking why he wanted them -- not why we don't like them.