Yes, you heard it right as Linux Kernel 5.8 is finally available now.
Linux 5.8 Kernel Features
- Qualcomm Adreno 405 / 640 / 650 open-source support.
- Intel Tiger Lake SAGV support.
Support for Nested AMD live migration with KVM.
– Initial support for booting POWER10 processors.
- Microsoft exFAT driver improvements.
Thunderbolt support on non-x86 systems.
Staging and IIO updates.
AMD SPI controller driver was merged.
Download the Linux Kernel 5.8 from this link.
Announcement from Linus:
So I didn't really expect this, but 5.8 looks to be one of our biggest
releases of all time.
As of -rc1, it's right up there with v4.9, which has long been our
biggest release by quite a bit in number of commits. Yes, 5.8-rc1 has
a couple fewer commits than 4.9-rc1 did, but in many ways it's a much
more comprehensive release despite that.
The 4.9 kernel was artificially big partly because of the greybus
subsystem that was merged in that release, but also because v4.8 had
had a longer rc series and thus there was more pent up development. In
5.8, we have no sign of those kinds of issues making the release
bigger - there's just simply a lot of development in there.
And there are other kernel releases that have had more new lines -
v4.12 ends up being the undisputed size champion in that regard,
simply because it had a _huge_ number of new lines due to lots of
register descriptions for the AMD GPU drivers. Other kernels have been
similarly big due to particular subsystems (v4.2 had another AMD GPU
driver line count bump, 2.6.29 had a big staging driver additions,
etc).
But again, 5.8 is up there with the best, despite not really having
any single thing that stands out. Yes, there's a couple of big driver
changes (habanalabs and atomisp) that are certainly part of it, but
it's not nearly as one-sided as some of the other historical big
releases have been.
The development is really all over the place: there's tons of fairly
fundamental core work and cleanups, but there is also lots of
filesystem work and obviously all the usual driver updates too. Plus
documentation and archiecture work.
In fact, while 5.8-rc1 is "up there with the best" when it comes to
both number of commits and number of new lines, it's actually the
outstanding champion when it comes to number of files changed. And
again, that's not because of some single tree-wide simple scripting
thing (the kernels with lots of SPDX license line changes have a lot
of files changed), but simply because of lots and lots of development
work.
So in the 5.8 merge window we have modified about 20% of all the files
in the kernel source repository. That's really a fairly big
percentage, and while some of it _is_ scripted, on the whole it's
really just the same pattern: 5.8 has simply seen a lot of
development.
IOW, 5.8 looks big. Really big.
In pure numbers: over 14k non-merge commits (over 15k counting
merges), ~800k new lines, and over 14 thousand files changed.
It's worth noting that despite the size, it doesn't necessarily look
like a particularly troublesome release at least so far. Yes, the pure
size made this merge window a bit more stressful than I like, because
I _really_ like to have a few days of calm at the end to look at some
of the pull requests in more detail. This time around that never
really happened. But I only really had two pull requests I ended up
wanting to go through in more detail, so it all worked out fine.
So the pure size of this merge window did make me (once again)
consider making it more of a hard rule that pull requests with new
features (as opposed to the second wave of pull requests with just
fixes) absolutely _have_ to come in during the first week of the merge
window, but honestly, _most_ of the pull requests did in fact do that.
No, not all, and it could have been a bit more organized, and maybe I
got snippy with somebody, but on the whole things were pretty smooth
despite the large size.
Famous last words. Let's see what happens during the rest of this release.
But at least right now, while 5.8 looks like a very large release, I
don't get the feeling that it's particularly troublesome.
Knock wood.
Appended is the merge-log as usual. If you didn't get the idea yet
(IT'S BIG!) the shortlog would be much too unwieldly, even more so
than usual.
Linus
