9月份，Linux内核开发人员格雷格•克罗-哈特曼(Greg Kroah-Hartman)在其个人博客上证实，Linux内核4.14是下一个LTS内核，这个内核将至少被支持两年;最近这个年限被延长到了六年。因此，Linux 4.14的开发周期比平常长了一星期，我们目睹了8个发行候选版本(rc)。
4.14 LTS“Fearless Coyote”现已问世
Linux之父莱纳斯•托瓦尔兹(Linus Torvalds)今天发布了代号为“Fearless Coyote”(无畏的土狼)的Linux内核4.14。托瓦尔兹在其Linux内核邮件列表上宣布：“附加的简短日志(shortlog)显然只针对自rc8以来的少量开发成果，确实很少。提交的代码不多，都是小代码。”
他还花了点时间提及0day机器人测试工具在如何日臻完善。这里所指的“机器人”(robot)是一个自动化安全漏洞，即检测出来的扫描内核代码的漏洞。
主要的功能特性
Linux内核4.14 LTS版本的主要功能特性是把异构内存管理合并到主线中。开发该功能是为了让进程地址空间可以被镜像，并确保系统内存被任何设备透明地使用。
另外一个重大变化是x86_64硬件上内存限制放宽松了，因而支持更大容量的内存。下面简要列出了你可能感兴趣的新功能特性：
- Vega方面的改进
- 继续致力于Cannonlake上的硬件支持
- 添加了对Zstd压缩的支持
- 面向EPYC服务器CPU的AMD安全内存加密
- 新的Realtek“rtlwifi”驱动程序
- R-Pi获得对HDMI CEC的支持
- 面向Android的F2FS调优
- Btrfs、EXT4和XFS方面的改进
- 改写了英特尔高速缓存质量监控代码
你可以在Phoronix上找到内容更全面的Linux内核4.14功能特性列表(https://www.phoronix.com/scan.php?page=article&item=linux-414-features&num=1)。托瓦尔兹声称4.14版本“令人痛苦”，敦促开发人员开始尽早完成工作。
4.14版本的源代码打包文件(tarball)可以从kernel.org(https://www.kernel.org/)来获取。
近日，Linux Torvalds 的一封邮件对 Linux 4.14 的部分功能更新进行了解读，或许你可以开始为这个版本做准备了，毕竟未来所有 Linux 开发者将与 4.14 版本度过很长一段时间。
一封发给全体Linux成员的内部信：Linux 4.14重大改进!
以下是邮件全文：
No surprises this week, although it is probably worth pointing out how
the 0day robot has been getting even better (it was very useful
before, but Fengguang has been working on making it even better, and
reporting the problems it has found).
Sure, some of the new reports turned out to be just 0day doing things
that just don't work (ie KASAN with old gcc versions, but also doing
things like loading old ISA drivers in situations that just don't make
sense - remember when you couldn't even ask if the hardware existed or
not, and just had to know), but even then it's been all good.
The appended shortlog is obviously only for the (small) haul since
rc8, and it really is tiny. Not very many commits, and they are small.
The biggest thing that stands out in the diffstat is the
"leaking_addresses" perl script, which is actually under active
development, but I put the first version in for 4.14 just so that
people could see that initial state and start looking at the end
result and perhaps ask themselves "should my code make these kernel
addresses visible to user space".
The actual changes will hopefully start percolating into 4.15, with
one notable llikely early change (which has been discussed extensively
on the list) being to just hash any "%p" addresses by default. We used
to have strict modes that just zeroed the address out, but that was
actually counter-productive, in that often people use the address as a
"kernel object identity" for debugging (or fro cross-correlation -
think network sockets), and so just clearing the pointer value makes
those kinds of uses pointless. But using a secure hash allows for
those kinds of identity uses, while not actually leaking the address
itself.
(Other situations where the actual address is relevant then need other
approaches - we'll be restricting /proc/kallsyms only to entities that
actually need them etc etc).
Anyway, apart from that one script, the rest of it really is
one-liners or "few-liners".
The most noticeable last-minute change is probably that we had to
revert the code that showed a good MHz value in /proc/cpuinfo even for
the modern "CPU picks frequency dynamically" case. It worked fine, but
it was much too expensive on machines with tens or hundreds of CPU
cores. There's a cunning plan, but it didn't make 4.14, so we'll get
it working and then back-port.
Anything else is pretty esoteric, you can just read the changelog..
And with this, the merge window for 4.15 is obviously open. As
mentioned in the late rc announcements, the extra week for rc8 means
that now Thanksgiving week ends up happening during the second half of
the merge window, and I'll be off on a family vacation.
We'll see how that goes.
I might decide that I'll extend the merge window if I feel that I
can't be responsive enough.
Or maybe you guys won't even notice, because I _will_ have my laptop
and internet access.
Or maybe I will just decide that 4.14 was a painful release, and any
late stragglers for 4.15 are not worth _another_ painful release, and
I'll just say "tough luck, you were late to the merge window, and I
felt more like being out in the sun than taking your second-week pull
request".
Because it really would be lovely to have a smaller and calmer release for 4.15.
Anyway, go out and test the new 4.14 release, that is slated to be the
next LTS kernel - and start sending me pull request for the 4.15 merge
window.
Linus
翻译：
这个星期没什么惊喜，虽然可能值得指出 0day 机器人如何变得更好了(这在之前非常有用，冯光一直在努力让它变得更好，并且报告发现的问题)。
附加的 shortlog 显然只适用于自 rrc8 以来的(小)运行，而且它确实很小，并不适合很多提交。在 diffstat 中突出的***事情是 “leaking_addresses”perl 脚本，这实际上是积极的发展，但***个版本是 4.14，以便人们可以看到初始状态并查看最终结果，也许问自己 “我的代码是否应该使这些内核地址对用户空间可见”。
实际的变化有望开始渗透到 4.15，其中一个值得注意的早期变化(在列表上被广泛讨论)是默认情况下对任何 “%p” 地址进行散列。我们以前有严格的模式，只是把地址清零，但实际上这是相反的，因为人们经常使用地址作为调试的核心对象(或者互相关 - 网络套接字)， 所以只要清除指针值就会使这些用途变得毫无意义，但是使用安全散列可以实现这些用途而不泄露地址本身(其他情况下，实际的地址是相关的)。
无论如何，除了那一个脚本，其余的是真的 one-liners 或者 "few-liners"。
最明显的变化可能是不得不还原 / proc / cpuinfo 中显示良好 MHz 值的代码现代 “CPU 动态挑选” 案例。它工作得很好，但是在数十或数百个 CPU 的机器上，它太昂贵了。
与此同时，4.15 的合并窗口显然是开放的，如果觉得扩大合并窗口不能有足够的响应。或者甚至不会注意到，因为我将拥有笔记本电脑和互联网接入。
无论如何，测试一下新的 4.14 版本，这是接下来 LTS 内核的样子，然后开始发送 4.15 合并请求窗口。
