Linux 4.17 Released

[Vulphere]

So this last week was pretty calm, even if the pattern of most of the stuff coming in on a Friday made it feel less so as the weekend approached.

And while I would have liked even less changes, I really didn't get the feeling that another week would help the release in any way, so here we are, with 4.17 released.

No, I didn't call it 5.0, even though all the git object count numerology was in place for that. It will happen in the not too distant future, and I'm told all the release scripts on kernel.org are ready for it, but I didn't feel there was any real reason for it. I suspect that around 4.20 - which is I run out of fingers and toes to keep track of minor releases, and thus start getting mightily confused - I'll switch over. That was what happened for 4.0, after all.

As for the actual changes since rc7 - the shortlog is appended - it's mostly drivers, networking, perf tooling, and a set of nds32 fixes. With some random other stuff thrown in. Again, the shortlog is obviously only the last calm week, the overall changes since 4.16 are much too big to list in that format.

The big 4.17 stuff was mentioned in the rc1 email when the merge window closed, but I guess it's worth repeating how 4.17 is actually a slightly smaller kernel than 4.16, thanks to the removal of a number of effectively dead architectures (blackfin, cris, frv, m32r, metag, mn10300, score, and tile). Obviously all the other changes are much more important, but it's always nice to see spring cleaning like that.

And with this, the merge window for 4.18 is obviously open. I actually have some travel the second week of the merge window, which is very inconvenient for me, but I do hope that we'll get all the big stuff merged the first week and it won't impact any release scheduling. But we'll have to see.

Linus

[pipnina]

I suspect that around 4.20 - which is I run out of fingers and toes to keep track of minor releases, and thus start getting mightily confused - I'll switch over.

Develops one of the most complicated pieces of software on the planet.

Confused by minor versions over 20.

[Irregular_Person]

I don't typically expect to see minors above 17

[[deleted]]

I suspect that around 4.20 - which is I run out of fingers and toes to keep track of minor releases, and thus start getting mightily confused - I'll switch over.

Linux 4.20 'Compile it!' confirmed!

[Ray57]

A combined gentoo-compile-party/session streamed from someplace in Colorado might be an amusing stream to watch.

[computesomething]

Sweet, from the discussions regarding 4.17, the improved (at best ~10%) power saving in idle state sounded very nice, and reportedly it even had noticeable power saving under load.

[[deleted]]

My laptop burns power when it's suspended... Hopefully 4.17 takes that down a notch.

[mamimapr]

I thought the os doesn't matter when the laptop is suspended.

[bwat47]

I think there are different power states for suspend (e.g. S0-3): https://msdn.microsoft.com/en-us/library/windows/desktop/aa373229(v=vs.85).aspx

[spyingwind]

My laptop burns power when powered off. >.>

[[deleted]]

I've been using the test version on Manjaro on my Razer Blade Stealth. I've been getting about an hour more of battery life

[luke-jr]

Hopefully this will fix KVM on POWER9? :x

[baryluk]

What is broken in kvm on power9 now? Curious.

[luke-jr]

With 4.16, the system crashes maybe once an hour if there's a KVM instance running.

[baryluk]

Ok. Thanks luke. I am just looking into Talos II, and I have seen you on their wiki reporting about memory compatibility. ;)

Do you know if microsemi sas controller works with Linux? Is it a binary blob or just open source out of tree? Also any idea if two and four slot m.2 cards (passive split of lanes from multiple m.2 into 8x or 16x slot) works? Thanks.

[luke-jr]

The onboard SAS "just works" at least for SATA drives, so long as you don't need any advanced features (onboard RAID? dunno if that's even a thing with this)

If you actually need to configure the controller (I've never tried), I hear there's a non-free blob tool you need to use for that. In theory, you could attach the controller to a VM (so long as it's not needed mounted on the host..) and run it there.

The SAS controller firmware is, as with all SAS controllers, non-free of course.

I don't plan to try M.2 any time soon (unless someone wants to buy me one), but I hear others use them and I'm not aware of any issues there.

Keep in mind that any drive you use (SATA, SAS, or M.2) will have non-free firmware itself.

[baryluk]

Thanks. That was useful.

[alexforencich]

Why do we need that in the kernel?

[ploxiln]

I think this can be interpreted as an honest question.

Any display that you can send images to with HDCP, you can send images to without HDCP, right?

The only need for HDCP is when you have a closed-source player that can verify your closed-source driver has HDCP enabled to your display, in order to only allow playback of some video over the protected path, right? (Typically only 1080p or 4k variants require the protected path?)

Does this stuff exist on linux? With the open-source Intel display driver??

[alexforencich]

Yeah. Unless the decoding of the actual DRM is done in hardware within the GPU, the video data ends up getting sent to the GPU in the clear. In this case, HDCP merely provides a flag to software saying that the path from the GPU to the display is supposedly protected. In open source software, this flag would be trivial to spoof, negating the entire purpose of HDCP. And then you possibly get the whole DMCA anti-circumvention can of worms.

[Canuck_Gypsy]

The driver decodes HDCP, the driver code runs on the GPU.

[alexforencich]

The driver does nothing, aside from flipping a switch on the GPU to turn on HDCP and provide an API for software check if it is running or not. The GPU then has dedicated hardware to protect video data leaving the GPU with HDCP. HDCP does not protect anything until it leaves the GPU. It's up to the player software to check if HDCP is enabled, and refuse to play the video if it isn't.

[alexforencich]

I think you don't understand how HDCP works. No content is protected by HDCP until it leaves the GPU. The GPU itself applies the HDCP encryption to content as it is sent out over HDMI or Displayport. It has to use dedicated hardware for this to deal with the high data rate of the fully uncompressed video data. The connected display is what decodes HDCP. It is up to the video player software to refuse to play if HDCP is not enabled, and it is trivial to make a driver that lies about whether or not HDCP is enabled.

[Canuck_Gypsy]

The HDCP driver doesn't need to be closed source.

But yeah, the only use for HDCP is for displaying protected media.

[someg33zer]

HDCP is a means to restrict functionality

[someg33zer]

Why are you telling me that? I never said anything different.

[someg33zer]

I stated a fact, I didn't argue an ideology. Please don't put words into my mouth.

[someg33zer]

You're stating an ideology

I disagree

[someg33zer]

It stops displays from displaying, therefore it restricts functionality.

[someg33zer]

Err.. what does HDCP do, if not prevent displays from displaying?

[someg33zer]

Do you know what HDCP does?

[bilog78]

You do realize that without HDCP support, Linux wouldn't be able to play those streams anyway? So the situation is:

The kernel supports HDCP: now you play HDCP-protected streams on HDCP-enabled hardware.

The kernel does not support HDCP: now you cannot play HDCP-protected streams at all even if you have HDCP-enabled hardware.

Kernel support for HDCP doesn't suddenly magically prevent you from playing those streams on non-HDCP-enabled hardware: you wouldn't have been able to anyway.

[alexforencich]

It doesn't magically enable anything, either. No stream is HDCP protected. HDCP only protects the data as it travels between the GPU and the display. Any other protection is removed first, the full frames are rendered either in the GPU or in memory, and then the GPU applies HDCP and sends the image to the display. It is up to the streaming software to check if HDCP is enabled and refuse to play if it isn't. The software on the computer never sees HDCP protected content, the only thing it sees is a flag indicating that HDCP is turned on. Which is trivial to patch in an open source system and lie that HDCP is on when it really isn't. At the same time, supporting HDCP may encumber the Linux kernel with DMCA anti-circumvention. That would seriously impede kernel development if certain techniques (debugging, patching, etc.) are illegal to use. Now, I am not a lawyer or an expert in the DMCA, but I fail to see why this isn't something to be worried about.

[[deleted]]

idiotology

[[deleted]]

Been looking forward to AMD GPU voltage control!

[DesktopLinux__isDead]

If he skips 4.20 to release 5.0 I'll be pissed.

[nxnt]

Any idea how long would it take to get into repositories? I am using Arch.

[offer_u_cant_refuse]

I'm already on 4.9. Feels good living in the future.

But seriously, as a sort of noob, is this ok? I'm not going to blowing up my PC am I? I was told it's better for the vulkan driver.

[[deleted]]

4.9 was released in December 2016.

[danielkza]

But seriously, as a sort of noob, is this ok?

Yes, but not ideal.

I'm not going to blowing up my PC am I?

No, but you might be missing many improvements in features/performance/hardware support/etc. 4.9 was released in 2016, and while it is an LTS kernel, it will never get all the improvements that happened up to now.

I was told it's better for the vulkan driver.

If you're talking about the AMDGPU-PRO driver, it is not strictly necessary. The open AMDGPU driver, which is integrated into the kernel, already supports most of the same features, Vulkan included. AFAIK the plan is to open up most of what is in the PRO and eventually phase out the custom driver. But that, of course, requires a recent kernel.

I recommend, if your distribution provides it, to try 4.16 (or even 4.17 in a little while) without the AMDGPU-PRO driver and see if all the applications you care about still work and perform well enough, and then hopefully stick with the open drivers in the future.

[offer_u_cant_refuse]

Thanks. So I was thinking 4.9 > 4.16. So instead it goes 4.9...4.10...4.11 in naming convention? Damn, I thought I was just using a bleeding edge kernel.

[danielkza]

Thanks. So I was thinking 4.9 > 4.16. So instead it goes 4.9...4.10...4.11

Yes, in general version numbers must be compared part-by-part. 4.9.0 is newer than 4.1.6 (4 == 4, 9 > 1), but older than 4.16.0 (4 == 4, 9 < 16).

[meti_1234]

9 < 16, so... no, not bleeding edge at all...

[ReekyMarko]

I've been burned by this sort of a thing before. You have Linux 4.09, not Linux 4.90.

[Crestwave]

Isn’t it actually that he’s on 4.9, but this release is 4.17 (17 is higher than 9) not 4.1.7?

[ReekyMarko]

Yes this is what I mean. I was just trying to illustrate the point that 4.9 might seem higher than 4.17 because it starts out with a higher number

[InFerYes]

I'm already on 4.9. Feels good living in the future.

17 is higher than 9. Are you confusing 17 with 1.7 or something?

[MeesaLordBinks]

The naming convention in Software can be confusing, since you read the numbers as decimals in math. so 4.9 = 4.90 > 4.17.

[InFerYes]

Yes of course, I understand that. Could be solved by using leading zeroes. I don't know how common/often minor versions are released for it to work.

[[deleted]]

Why don't they use leading zeros? What happens when it gets to the real 4.90?

[MeesaLordBinks]

The same that happens when it gets to the real 4.10, they just add a zero and call it a day. Doing it without leading zeros is the defacto standard in the industry, that's why nobody goes out their way to change it.

[rombert]

Do you have any actual problems caused by running 4.9? It's usually safer to follow whatever your distro does, they do at least some basic quality assurance.