9月份，Linux內(nèi)核開(kāi)發(fā)人員格雷格•克羅-哈特曼(Greg Kroah-Hartman)在其個(gè)人博客上證實(shí)，Linux內(nèi)核4.14是下一個(gè)LTS內(nèi)核，這個(gè)內(nèi)核將至少被支持兩年;近這個(gè)年限被延長(zhǎng)到了六年。因此，Linux 4.14的開(kāi)發(fā)周期比平常長(zhǎng)了一星期，我們目睹了8個(gè)發(fā)行候選版本(rc)。
4.14 LTS“Fearless Coyote”現(xiàn)已問(wèn)世
Linux之父萊納斯•托瓦爾茲(Linus Torvalds)今天發(fā)布了代號(hào)為“Fearless Coyote”(無(wú)畏的土狼)的Linux內(nèi)核4.14。托瓦爾茲在其Linux內(nèi)核郵件列表上宣布：“附加的簡(jiǎn)短日志(shortlog)顯然只針對(duì)自rc8以來(lái)的少量開(kāi)發(fā)成果，確實(shí)很少。提交的代碼不多，都是小代碼。”
他還花了點(diǎn)時(shí)間提及0day機(jī)器人測(cè)試工具在如何日臻完善。這里所指的“機(jī)器人”(robot)是一個(gè)自動(dòng)化安全漏洞，即檢測(cè)出來(lái)的掃描內(nèi)核代碼的漏洞。
主要的功能特性
Linux內(nèi)核4.14 LTS版本的主要功能特性是把異構(gòu)內(nèi)存管理合并到主線中。開(kāi)發(fā)該功能是為了讓進(jìn)程地址空間可以被鏡像，并確保系統(tǒng)內(nèi)存被任何設(shè)備透明地使用。
另外一個(gè)重大變化是x86_64硬件上內(nèi)存限制放寬松了，因而支持更大容量的內(nèi)存。下面簡(jiǎn)要列出了你可能感興趣的新功能特性：
    Vega方面的改進(jìn)
    繼續(xù)致力于Cannonlake上的硬件支持
    添加了對(duì)Zstd壓縮的支持
    面向EPYC服務(wù)器CPU的AMD安全內(nèi)存加密
    新的Realtek“rtlwifi”驅(qū)動(dòng)程序
    R-Pi獲得對(duì)HDMI CEC的支持
    面向Android的F2FS調(diào)優(yōu)
    Btrfs、EXT4和XFS方面的改進(jìn)
    改寫(xiě)了英特爾高速緩存質(zhì)量監(jiān)控代碼
你可以在Phoronix上找到內(nèi)容更全面的Linux內(nèi)核4.14功能特性列表(https://www.phoronix.com/scan.php?page=article&item=linux-414-features&num=1)。托瓦爾茲聲稱4.14版本“令人痛苦”，敦促開(kāi)發(fā)人員開(kāi)始盡早完成工作。
4.14版本的源代碼打包文件(tarball)可以從kernel.org(https://www.kernel.org/)來(lái)獲取。
近日，Linux Torvalds 的一封郵件對(duì) Linux 4.14 的部分功能更新進(jìn)行了解讀，或許你可以開(kāi)始為這個(gè)版本做準(zhǔn)備了，畢竟未來(lái)所有 Linux 開(kāi)發(fā)者將與 4.14 版本度過(guò)很長(zhǎng)一段時(shí)間。
一封發(fā)給全體Linux成員的內(nèi)部信：Linux 4.14重大改進(jìn)!
以下是郵件全文：
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
翻譯：
這個(gè)星期沒(méi)什么驚喜，雖然可能值得指出 0day 機(jī)器人如何變得更好了(這在之前非常有用，馮光一直在努力讓它變得更好，并且報(bào)告發(fā)現(xiàn)的問(wèn)題)。
附加的 shortlog 顯然只適用于自 rrc8 以來(lái)的(小)運(yùn)行，而且它確實(shí)很小，并不適合很多提交。在 diffstat 中突出的大事情是 “leaking_addresses”perl 腳本，這實(shí)際上是積極的發(fā)展，但先進(jìn)個(gè)版本是 4.14，以便人們可以看到初始狀態(tài)并查看終結(jié)果，也許問(wèn)自己 “我的代碼是否應(yīng)該使這些內(nèi)核地址對(duì)用戶空間可見(jiàn)”。
實(shí)際的變化有望開(kāi)始滲透到 4.15，其中一個(gè)值得注意的早期變化(在列表上被廣泛討論)是默認(rèn)情況下對(duì)任何 “%p” 地址進(jìn)行散列。我們以前有嚴(yán)格的模式，只是把地址清零，但實(shí)際上這是相反的，因?yàn)槿藗兘?jīng)常使用地址作為調(diào)試的核心對(duì)象(或者互相關(guān) - 網(wǎng)絡(luò)套接字)， 所以只要清除指針值就會(huì)使這些用途變得毫無(wú)意義，但是使用安全散列可以實(shí)現(xiàn)這些用途而不泄露地址本身(其他情況下，實(shí)際的地址是相關(guān)的)。
無(wú)論如何，除了那一個(gè)腳本，其余的是真的 one-liners 或者 "few-liners"。
明顯的變化可能是不得不還原 / proc / cpuinfo 中顯示良好 MHz 值的代碼現(xiàn)代 “CPU 動(dòng)態(tài)挑選” 案例。它工作得很好，但是在數(shù)十或數(shù)百個(gè) CPU 的機(jī)器上，它太昂貴了。
與此同時(shí)，4.15 的合并窗口顯然是開(kāi)放的，如果覺(jué)得擴(kuò)大合并窗口不能有足夠的響應(yīng)?；蛘呱踔敛粫?huì)注意到，因?yàn)槲覍碛泄P記本電腦和互聯(lián)網(wǎng)接入。
無(wú)論如何，測(cè)試一下新的 4.14 版本，這是接下來(lái) LTS 內(nèi)核的樣子，然后開(kāi)始發(fā)送 4.15 合并請(qǐng)求窗口。