9月份，Linux內(nèi)核開發(fā)人員格雷格•克羅-哈特曼(Greg Kroah-Hartman)在其個人博客上證實，Linux內(nèi)核4.14是下一個LTS內(nèi)核，這個內(nèi)核將至少被支持兩年;最近這個年限被延長到了六年。因此，Linux 4.14的開發(fā)周期比平常長了一星期，我們目睹了8個發(fā)行候選版本(rc)。

4.14 LTS“Fearless Coyote”現(xiàn)已問世

Linux之父萊納斯•托瓦爾茲(Linus Torvalds)今天發(fā)布了代號為“Fearless Coyote”(無畏的土狼)的Linux內(nèi)核4.14。托瓦爾茲在其Linux內(nèi)核郵件列表上宣布：“附加的簡短日志(shortlog)顯然只針對自rc8以來的少量開發(fā)成果，確實很少。提交的代碼不多，都是小代碼。”

他還花了點(diǎn)時間提及0day機(jī)器人測試工具在如何日臻完善。這里所指的“機(jī)器人”(robot)是一個自動化安全漏洞，即檢測出來的掃描內(nèi)核代碼的漏洞。

主要的功能特性

Linux內(nèi)核4.14 LTS版本的主要功能特性是把異構(gòu)內(nèi)存管理合并到主線中。開發(fā)該功能是為了讓進(jìn)程地址空間可以被鏡像，并確保系統(tǒng)內(nèi)存被任何設(shè)備透明地使用。

另外一個重大變化是x86_64硬件上內(nèi)存限制放寬松了，因而支持更大容量的內(nèi)存。下面簡要列出了你可能感興趣的新功能特性：

• Vega方面的改進(jìn)
• 繼續(xù)致力于Cannonlake上的硬件支持
• 添加了對Zstd壓縮的支持
• 面向EPYC服務(wù)器CPU的AMD安全內(nèi)存加密
• 新的Realtek“rtlwifi”驅(qū)動程序
• R-Pi獲得對HDMI CEC的支持
• 面向Android的F2FS調(diào)優(yōu)
• Btrfs、EXT4和XFS方面的改進(jìn)
• 改寫了英特爾高速緩存質(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版本“令人痛苦”，敦促開發(fā)人員開始盡早完成工作。

4.14版本的源代碼打包文件(tarball)可以從kernel.org(https://www.kernel.org/)來獲取。

近日，Linux Torvalds 的一封郵件對 Linux 4.14 的部分功能更新進(jìn)行了解讀，或許你可以開始為這個版本做準(zhǔn)備了，畢竟未來所有 Linux 開發(fā)者將與 4.14 版本度過很長一段時間。

一封發(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

翻譯：

這個星期沒什么驚喜，雖然可能值得指出 0day 機(jī)器人如何變得更好了(這在之前非常有用，馮光一直在努力讓它變得更好，并且報告發(fā)現(xiàn)的問題)。

附加的 shortlog 顯然只適用于自 rrc8 以來的(小)運(yùn)行，而且它確實很小，并不適合很多提交。在 diffstat 中突出的***事情是 “leaking_addresses”perl 腳本，這實際上是積極的發(fā)展，但***個版本是 4.14，以便人們可以看到初始狀態(tài)并查看最終結(jié)果，也許問自己 “我的代碼是否應(yīng)該使這些內(nèi)核地址對用戶空間可見”。

實際的變化有望開始滲透到 4.15，其中一個值得注意的早期變化(在列表上被廣泛討論)是默認(rèn)情況下對任何 “%p” 地址進(jìn)行散列。我們以前有嚴(yán)格的模式，只是把地址清零，但實際上這是相反的，因為人們經(jīng)常使用地址作為調(diào)試的核心對象(或者互相關(guān) - 網(wǎng)絡(luò)套接字)， 所以只要清除指針值就會使這些用途變得毫無意義，但是使用安全散列可以實現(xiàn)這些用途而不泄露地址本身(其他情況下，實際的地址是相關(guān)的)。

無論如何，除了那一個腳本，其余的是真的 one-liners 或者 "few-liners"。

最明顯的變化可能是不得不還原 / proc / cpuinfo 中顯示良好 MHz 值的代碼現(xiàn)代 “CPU 動態(tài)挑選” 案例。它工作得很好，但是在數(shù)十或數(shù)百個 CPU 的機(jī)器上，它太昂貴了。

與此同時，4.15 的合并窗口顯然是開放的，如果覺得擴(kuò)大合并窗口不能有足夠的響應(yīng)。或者甚至不會注意到，因為我將擁有筆記本電腦和互聯(lián)網(wǎng)接入。

無論如何，測試一下新的 4.14 版本，這是接下來 LTS 內(nèi)核的樣子，然后開始發(fā)送 4.15 合并請求窗口。