---

Linux 4.14 rc1

Yes, I realize this is a day early, and yes, I realize that if I had
waited until tomorrow, I would also have hit the 26th anniversary of
the Linux-0.01 release, but neither of those undeniable facts made me
want to wait with closing the mege window.

This has been an "interesting" merge window. It's not actually all
that unusual in size - I think it's shaping to be a pretty regular
release after 4.13 that was smallish. But unlike 4.13 it also wasn't a
completely smooth merge window, and honestly, I _really_ didn't want
to wait for any possible straggling pull requests.

Don't get me wrong - things don't look bad, but I hate it when I find
issues during the merge window that I feel should have been noticed
before the code made it to me, and it happened a few times this
release.

Admittedly, some of it was simply because we had some unusual
activity. For example, on the x86 VM side, 4.14 doesn't just have
_one_ new core memory management feature, but three: 5-level page
tables, ASID support (it's called "PCID" on x86 for reasons that are
not good) and the AMD memory encryption support. So the fact that we
had a few hiccups is very understandable, and in fact it should amaze
everybody just how smoothly the 5-level page table code integration
seems to have gone, for example.

So 4.14 is getting some very core new functionality.

Obviously, as usual, those kinds of core changes are absolutely
dwarfed by all the device driver updates, that as usual are the bulk
of the patches. This time around, particularly notable is a late
addition to the merge window - or rather, a late removal - in that
we've finally gotten rid of the firmware images from the kernel tree.
That's because people haven't used them for the last few years, since
there's a separate firmware image repository.

But there's changes all over. Documentation, architecture updates,
filesystems, networking, tooling. This was not a small release, even
if I had kind of expected that with much of Europe on vacation in
August we'd have seen a slow-down. Nope.

Anyway, as always, the shortlog is much too big to post, so appended
is the "mergelog", and as always the credit in the merge log goes not
to who wrote the patches, but to the maintainer who actually sent it
to me for merging. So there's about 90 maintainers mentioned there,
but it should be noted that we have 1500+ individual authors for the
11,500+ individual non-merge commits. So this is very much just a very
high-level overview of the merges I've done, and if you want to see
details, you'll need to go look at the git tree logs.

Linus

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis