linux: add conditional patch for timeconst.pl

PATCH Superseded gustavo.zacarias at free-electrons.com 4 participants 8 messages Feb 7, 2016 – Feb 10, 2016

lore

Share & tools

lore

gustavo.zacarias at free-electrons.com

author

2016-02-07 13:41 UTC #0 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

From: Gustavo Zacarias <[email protected]>

Kernels older than 3.9 (not counting stable releases) used the timeconst.pl perl script for their build process.
The problem with this script is that it used deprecated perl features, namely defined(@array) which was removed for the perl 5.22 release, causing build failure of older kernels on newer distributions.

To fix this instead of going the hard way (moving to the new timeconst.bc script) use the easy way by patching timeconst.pl with an upstream patch used for stable releases.

First try a dry-run on the patch to see if it applies, if it does then call a proper APPLY_PATCHES to it.

Tested against an arbitrary 2.6.30 kernel (applies and builds), against 4.4.1 for a missing timeconst.pl (does not apply since it's missing) and 3.8.13 (does not apply since it's fixed already).

Known broken distributions: fedora 23.

Signed-off-by Gustavo Zacarias <[email protected]>

---
v2: rebase on top of master

 ...nst.pl-Eliminate-Perl-warning.patch.conditional | 45 ++++++++++++++++++++++
 linux/linux.mk                                     | 10 +++++
 2 files changed, 55 insertions(+)
 create mode 100644 linux/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional

linux/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional new file +45 -0

new file mode 100644
index 0000000..02abadd
@@ -0,0 +1,45 @@
+From 63a3f603413ffe82ad775f2d62a5afff87fd94a0 Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <[email protected]>
+Date: Thu, 7 Feb 2013 17:14:08 -0800
+Subject: [PATCH] timeconst.pl: Eliminate Perl warning
+
+defined(@array) is deprecated in Perl and gives off a warning.
+Restructure the code to remove that warning.
+
+[ hpa: it would be interesting to revert to the timeconst.bc script.
+  It appears that the failures reported by akpm during testing of
+  that script was due to a known broken version of make, not a problem
+  with bc.  The Makefile rules could probably be restructured to avoid
+  the make bug, or it is probably old enough that it doesn't matter. ]
+
+Reported-by: Andi Kleen <[email protected]>
+Signed-off-by: H. Peter Anvin <[email protected]>
+Cc: Andrew Morton <[email protected]>
+Cc: <[email protected]>
+Signed-off-by: Gustavo Zacarias <[email protected]>
+---
+Patch status: upstream
+
+ kernel/timeconst.pl | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
+index eb51d76..3f42652 100644
+--- a/kernel/timeconst.pl
++++ b/kernel/timeconst.pl
+@@ -369,10 +369,8 @@ if ($hz eq '--can') {
+ 		die "Usage: $0 HZ\n";
+ 	}
+ 
+-	@val = @{$canned_values{$hz}};
+-	if (!defined(@val)) {
+-		@val = compute_values($hz);
+-	}
++	$cv = $canned_values{$hz};
++	@val = defined($cv) ? @$cv : compute_values($hz);
+ 	output($hz, @val);
+ }
+ exit 0;
+-- 
+2.4.10
+

linux/linux.mk +10 -0

index 578fea1..7e20255 100644
@@ -184,6 +184,16 @@ endef
 
 LINUX_POST_PATCH_HOOKS += LINUX_APPLY_LOCAL_PATCHES
 
+# Older linux kernels use deprecated perl constructs in timeconst.pl
+# that were removed for perl 5.22+ so it breaks on newer distributions
+# Try a dry-run patch to see if this applies, if it does go ahead
+define LINUX_TRY_PATCH_TIMECONST
+	@if patch -p1 --dry-run -f -s -d $(@D) <$(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >/dev/null ; then \
+		$(APPLY_PATCHES) $(@D) $(LINUX_PKGDIR) 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional ; \
+	fi
+endef
+LINUX_POST_PATCH_HOOKS += LINUX_TRY_PATCH_TIMECONST
+
 ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
 LINUX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
 else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)

Signature · 1 line

2.4.10

Thomas Petazzoni

2016-02-07 14:50 UTC #1 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

Hello,

linux/linux.mk endef · line 195

Quoted 9 lines · gustavo.zacarias at free-electrons.com

linux/linux.mk +9 -0

+# Older linux kernels use deprecated perl constructs in timeconst.pl
+# that were removed for perl 5.22+ so it breaks on newer distributions
+# Try a dry-run patch to see if this applies, if it does go ahead
+define LINUX_TRY_PATCH_TIMECONST
+	@if patch -p1 --dry-run -f -s -d $(@D) <$(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >/dev/null ; then \
+		$(APPLY_PATCHES) $(@D) $(LINUX_PKGDIR) 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional ; \
+	fi
+endef
+LINUX_POST_PATCH_HOOKS += LINUX_TRY_PATCH_TIMECONST

I really don't like this hack, but I am not sure to see a better solution. So I'll leave a few days before applying to see if other people chime in with other comments/suggestions, and if nobody comments, I'll apply.

Thanks,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Arnout Vandecappelle

2016-02-09 23:08 UTC #2 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

In reply to gustavo.zacarias at free-electrons.com

Quoted 12 lines · gustavo.zacarias at free-electrons.com

From: Gustavo Zacarias <[email protected]>
Kernels older than 3.9 (not counting stable releases) used the timeconst.pl perl script for their build process.
The problem with this script is that it used deprecated perl features, namely defined(@array) which was removed for the perl 5.22 release, causing build failure of older kernels on newer distributions.
To fix this instead of going the hard way (moving to the new timeconst.bc script) use the easy way by patching timeconst.pl with an upstream patch used for stable releases.

Quoted 8 lines

First try a dry-run on the patch to see if it applies, if it does then call a proper APPLY_PATCHES to it.
Tested against an arbitrary 2.6.30 kernel (applies and builds), against 4.4.1 for a missing timeconst.pl (does not apply since it's missing) and 3.8.13 (does not apply since it's fixed already).
Known broken distributions: fedora 23.

and debian testing (stretch) and unstable (sid).

As Thomas said, it's dirty, but we really need this.

Quoted 10 lines

Signed-off-by Gustavo Zacarias <[email protected]>

---
v2: rebase on top of master

 ...nst.pl-Eliminate-Perl-warning.patch.conditional | 45 ++++++++++++++++++++++
 linux/linux.mk                                     | 10 +++++
 2 files changed, 55 insertions(+)
 create mode 100644 linux/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional

[snip]

Quoted 5 lines

linux/linux.mk +0 -0
index 578fea1..7e20255 100644

linux/linux.mk endef · line 192

Quoted 9 lines

linux/linux.mk +6 -0

@@ -184,6 +184,16 @@ endef
 
 LINUX_POST_PATCH_HOOKS += LINUX_APPLY_LOCAL_PATCHES
 
+# Older linux kernels use deprecated perl constructs in timeconst.pl
+# that were removed for perl 5.22+ so it breaks on newer distributions
+# Try a dry-run patch to see if this applies, if it does go ahead
+define LINUX_TRY_PATCH_TIMECONST
+	@if patch -p1 --dry-run -f -s -d $(@D) <$(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >/dev/null ; then \
+		$(APPLY_PATCHES) $(@D) $(LINUX_PKGDIR) 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional ; \

The only reason to use APPLY_PATCHES is that it updates .applied_patches_list,
right? In that case, perhaps it's better to do that directly here. So instead of a dry-run, just apply the patch right away, and if it succeeds add it to .applied_patches_list.

linux/linux.mk endef · line 195

Quoted 3 lines

linux/linux.mk +3 -0

+	fi
+endef
+LINUX_POST_PATCH_HOOKS += LINUX_TRY_PATCH_TIMECONST

This is a patch that we probably _do_ want to apply even in case of
OVERRIDE_SRCDIR. So maybe add it to LINUX_PRE_CONFIGURE_HOOKS instead. Even though that's even more of a hack (and conflicts with the out-of-tree build support).

Regards,
Arnout

Quoted 5 lines

linux/linux.mk +1 -0

+
 ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
 LINUX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
 else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Gustavo Zacarias

author

2016-02-09 23:19 UTC #3 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

Quoted 3 lines · Arnout Vandecappelle

and debian testing (stretch) and unstable (sid).
As Thomas said, it's dirty, but we really need this.

Hi Arnout.
Yes, i couldn't figure out a cleaner way to do this, continues below...

Quoted 4 lines

The only reason to use APPLY_PATCHES is that it updates .applied_patches_list,
right? In that case, perhaps it's better to do that directly here. So instead of a dry-run, just apply the patch right away, and if it succeeds add it to .applied_patches_list.

I could have probed the timeconst.pl file presence and relevancy (if it contains defined(@array)...), but then a dry-run patch does that for me just fine with the proper parameters.
Yes, that's the reason for APPLY_PATCHES, however since it's already there why bother duplicating code?
Also thought of extending apply-patches.sh to add an option for try-do/discard, but i believe it's a double-edged sword and not worth it quite yet.

Quoted 4 lines

This is a patch that we probably _do_ want to apply even in case of
OVERRIDE_SRCDIR. So maybe add it to LINUX_PRE_CONFIGURE_HOOKS instead. Even though that's even more of a hack (and conflicts with the out-of-tree build support).

Possibly, let's hear other people thoughts on this. Regards.

Arnout Vandecappelle

2016-02-10 00:37 UTC #4 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

Quoted 9 lines · Gustavo Zacarias

Quoted 3 lines · Arnout Vandecappelle
and debian testing (stretch) and unstable (sid).
As Thomas said, it's dirty, but we really need this.
Hi Arnout.
Yes, i couldn't figure out a cleaner way to do this, continues below...

Quoted 8 lines

Quoted 4 lines
The only reason to use APPLY_PATCHES is that it updates .applied_patches_list,
right? In that case, perhaps it's better to do that directly here. So instead of a dry-run, just apply the patch right away, and if it succeeds add it to .applied_patches_list.
I could have probed the timeconst.pl file presence and relevancy (if it contains defined(@array)...), but then a dry-run patch does that for me just fine with the proper parameters.

My thoughts exactly.

Quoted 2 lines

Yes, that's the reason for APPLY_PATCHES, however since it's already there why bother duplicating code?

Well, you're already duplicating code because you first to patch and then
APPLY_PATCHES. My idea was something like:

	$(Q)cd $(@D); patch -p1 -f -s >/dev/null 2>&1 \
		< $(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional \
		&& echo 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >

.applied_patches_list

But really it's equally hacky so it doesn't matter much. Actually, my version
is especially hacky because it relies on the fact that the patch has a single hunk so it will always pass or fail atomically.

Quoted 2 lines

Also thought of extending apply-patches.sh to add an option for try-do/discard, but i believe it's a double-edged sword and not worth it quite yet.

I considered that as well, like making it handle *.conditional this way. But
since this is the only patch for the time being, it's a bit redundant...

Bottom line: keep it as it is.

Regards,
Arnout

Quoted 9 lines

Quoted 5 lines
This is a patch that we probably _do_ want to apply even in case of
OVERRIDE_SRCDIR. So maybe add it to LINUX_PRE_CONFIGURE_HOOKS instead. Even though that's even more of a hack (and conflicts with the out-of-tree build support).
Possibly, let's hear other people thoughts on this. Regards.

Signature · 6 lines

Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Gustavo Zacarias

author

2016-02-10 01:27 UTC #5 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

Quoted 11 lines · Arnout Vandecappelle

Well, you're already duplicating code because you first to patch and then
APPLY_PATCHES. My idea was something like:
	$(Q)cd $(@D); patch -p1 -f -s >/dev/null 2>&1 \
		< $(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional \
		&& echo 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >
.applied_patches_list
But really it's equally hacky so it doesn't matter much. Actually, my version
is especially hacky because it relies on the fact that the patch has a single hunk so it will always pass or fail atomically.

Remember that this will leave a reject file behind for the case where the kernel is already patched (few releases, but still...)

Quoted 5 lines

I considered that as well, like making it handle *.conditional this way. But
since this is the only patch for the time being, it's a bit redundant...
Bottom line: keep it as it is.

If the need arises with one or two more patches like this then yes, we can add some *.patch.maybe logic (personally i wouldn't call it conditional since a condition must be met, though 'maybe' sucks as well). Regards.

Peter Korsgaard

2016-02-10 07:11 UTC #6 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

In reply to Arnout Vandecappelle

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Hi,

Quoted 6 lines

Quoted 1 line
+LINUX_POST_PATCH_HOOKS += LINUX_TRY_PATCH_TIMECONST
This is a patch that we probably _do_ want to apply even in case of
OVERRIDE_SRCDIR. So maybe add it to LINUX_PRE_CONFIGURE_HOOKS instead. Even though that's even more of a hack (and conflicts with the out-of-tree build support).

We have so far said that it is the responsibility of the user overriding to handle all patches they need, and it imho makes sense here as well. If they build the kernel manually outside buildroot they also need to patch this.

Signature · 1 line

Bye, Peter Korsgaard

Peter Korsgaard

2016-02-10 07:12 UTC #7 lore raw

PATCH v2 1/1 linux: add conditional patch for timeconst.pl

In reply to gustavo.zacarias at free-electrons.com

Quoted 20 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"gustavo" == gustavo zacarias <[email protected]> writes:
From: Gustavo Zacarias <[email protected]> Kernels older than 3.9 (not counting stable releases) used the timeconst.pl perl script for their build process.
The problem with this script is that it used deprecated perl features, namely defined(@array) which was removed for the perl 5.22 release, causing build failure of older kernels on newer distributions.
To fix this instead of going the hard way (moving to the new timeconst.bc script) use the easy way by patching timeconst.pl with an upstream patch used for stable releases.
First try a dry-run on the patch to see if it applies, if it does then call a proper APPLY_PATCHES to it.
Tested against an arbitrary 2.6.30 kernel (applies and builds), against 4.4.1 for a missing timeconst.pl (does not apply since it's missing) and 3.8.13 (does not apply since it's fixed already).

Quoted 5 lines

Known broken distributions: fedora 23.
Signed-off-by Gustavo Zacarias <[email protected]>
---
v2: rebase on top of master

Yes, I'm afraid we need this :/

Committed, thanks.

Signature · 1 line

Bye, Peter Korsgaard