Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: all: require Linux kernel version 2.6.32 #45964

Open
OneOfOne opened this issue May 5, 2021 · 14 comments
Open

proposal: all: require Linux kernel version 2.6.32 #45964

OneOfOne opened this issue May 5, 2021 · 14 comments
Labels
Projects
Milestone

Comments

@OneOfOne
Copy link
Contributor

@OneOfOne OneOfOne commented May 5, 2021

The last version of 2.6.23(.17) was released on February 2008 src.
The current CentOS LTS (v7) uses kernel 3.10 src.
Debian's minimum is 3.16 src.

A quick search shows lot of random issues that could have been avoided by supported a slightly newer kernel.

This is a request to bump the minimum required kernel version to at least 3.10.

@mvdan
Copy link
Member

@mvdan mvdan commented May 5, 2021

I support this change. Other GOOS variants fairly regularly drop support for older versions, and Linux 2.x hasn't had any upstream support at all since 2016 (2.6.32 got extended by Ubuntu/RHEL, other 2.x versions went EOL by 2012). Supporting dozens of Linux versions at once adds cost to maintenance and code complexity, makes testing more difficult, etc.

Worth noting that Debian Stretch, now "oldstable", has long-term support until mid-2022, and is on Linux 3.16 like you say. The actual stable release is on Linux 4.19, which is supported by upstream until 2024.

Similarly, CentOS v7 using Linux 3.10 is supported until 2024. So it seems like we could consider another bump sometime after.

@tklauser tklauser changed the title runtime: bump minimum linux kernel version all: bump minimum linux kernel version May 5, 2021
@andrius4669
Copy link
Contributor

@andrius4669 andrius4669 commented May 7, 2021

glibc now also requires at least 3.2 version since 2.27 (announcement) for all architectures, including x86 ones.
The only issue I can imagine at the moment is old kernels used in OpenVZ VPSes, but they're starting becoming a problem for newer debian versions already.
One I have is currently running "2.6.32-042stab134.7" and debian stretch works on it (uses glibc 2.24), however updating to jessie is not possible due to its use of glibc 2.28.
For non-x86 architectures this shouldn't be an issue, which was also possibly the reason (or at least was part of) why glibc delayed their requirement for 3.2 kernel only for x86 architectures (they required 3.2 kernel in 2.25 version on other architectures).

@networkimprov
Copy link

@networkimprov networkimprov commented May 16, 2021

@ianlancetaylor perhaps this should be a proposal?

@ianlancetaylor ianlancetaylor changed the title all: bump minimum linux kernel version proposal: bump minimum linux kernel version May 17, 2021
@gopherbot gopherbot added this to the Proposal milestone May 17, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals May 17, 2021
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 17, 2021

Thanks, moved into proposal process.

@rsc rsc changed the title proposal: bump minimum linux kernel version proposal: all: raise minimum required Linux kernel version May 19, 2021
@rsc rsc moved this from Incoming to Active in Proposals May 19, 2021
@rsc
Copy link
Contributor

@rsc rsc commented May 19, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

@rsc rsc commented May 26, 2021

glibc requires 3.2. CentOS apparently requires 3.10.
What are we thinking of changing the minimum to?

And what are the benefits of bumping the minimum?
The link in the top comment is a search for [kernel 2.6.23] in the issue tracker.
Not all of them are bugs in 2.6.23 kernels.

Is there code we will be able to delete, like when we dropped XP?
Would we make Go binaries crash at startup if running on an old kernel?

@rsc
Copy link
Contributor

@rsc rsc commented Jun 2, 2021

We are still trying to understand this change, specifically
the exact details (which version? do we take the time to check kernel version and crash at startup on old kernels?)
and benefits (which code can be simplified or deleted?).

Any thoughts?

@mvdan
Copy link
Member

@mvdan mvdan commented Jun 2, 2021

I'll give my opinion on those questions, but I'm not the author of this proposal.

which version?

I think changing the minimum to 3.10 would be sensible, given the Linux distro info given above. I don't see a clear reason to go lower than that; even if glibc still supports 3.2 today, that kernel version went EOL in 2018 and isn't used by any supported Linux distro that I can find.

do we take the time to check kernel version and crash at startup on old kernels

We don't do that check right now with our current minimum, right? Is a new minimum different from the existing minimum, given that we're choosing it to be very conservative?

which code can be simplified or deleted?

To me, one of the main benefits is testing. I'd assume that we want to have a GOOS=linux builder running the oldest version of the kernel we support, to have more confidence that it actually works as advertised. That's a lot harder to do if that version is EOL, and isn't used by any maintained distro.

Even if one wanted to have GOOS=linux builders at multiple major versions of Linux (maybe popular LTS versions), bumping the minimum would hopefully mean fewer of those versions to worry about.

Asking for a summary of code that could be simplified, or issues that could be closed, seems reasonable. I'm not experienced in this area, but with five minutes of grepping I found five likely candidates:

// On Linux the accept4 system call was introduced in 2.6.28

// pipe2 was added in 2.6.27 and our minimum requirement is 2.6.23, so it

// in 2.6.22, Released, 8 July 2007) then fall back to utimes

// Try accept4 first for Android, then try accept for kernel older than 2.6.28

// On older kernels (before 2.6.24) the function can incorrectly

@rsc
Copy link
Contributor

@rsc rsc commented Jun 9, 2021

iant points out that timerfd was added in 2.6.25 and we probably want to depend on it for time.ExternalNow, so we should bump at least that far. And the examples show we could bump to at least 2.6.28 to simplify some code.

bradfitz points out that Synology 6.2 ships with 2.6.32.
CentOS 6 (out of support but clearly still used) is running 2.6.32 as well.

So maybe we should raise to 2.6.32, which will let us eliminate some very old things, keep some existing known use cases working, and seems not to add any known burden compared to newer versions.

Thoughts on raising to 2.6.32?

@OneOfOne
Copy link
Contributor Author

@OneOfOne OneOfOne commented Jun 9, 2021

That would clean all of checks in the go runtime except one that requires 4.5+, sounds good!

@mvdan
Copy link
Member

@mvdan mvdan commented Jun 9, 2021

Bumping fewer versions is certainly better than bumping none :) We can always revisit for a newer Linux version in a couple of years.

@andig
Copy link
Contributor

@andig andig commented Jun 10, 2021

bradfitz points out that Synology 6.2 ships with 2.6.32.
CentOS 6 (out of support but clearly still used) is running 2.6.32 as well.

So maybe we should raise to 2.6.32, which will let us eliminate some very old things, keep some existing known use cases working, and seems not to add any known burden compared to newer versions.

Thoughts on raising to 2.6.32?

I'm not a linux pro, but Synology 6.2.4 on my NAS shows:

admin@NAS:~$ uname -a
Linux NAS 4.4.59+ #25556 SMP PREEMPT Thu Mar 4 18:03:46 CST 2021 x86_64 GNU/Linux synology_apollolake_218+

Suggestions above seem to target on 3.10, is 2.6.32 really a requirement?

@rsc
Copy link
Contributor

@rsc rsc commented Jun 10, 2021

We know of users of Go programs built for Synology 6.2 using 2.6.32, and we know of users of CentOS 6 using 2.6.32.

Suggestions above seem to target on 3.10, is 2.6.32 really a requirement?

The clear downside of 3.10 over 2.6.32 is dropping support for those systems, where we know of real instances where Go is running today.

What is the upside of 3.10 over 2.6.32?

@rsc rsc changed the title proposal: all: raise minimum required Linux kernel version proposal: all: require Linux kernel version 2.6.32 Jun 16, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Jun 16, 2021

Retitled to specify 2.6.32. Does anyone object to this change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants