The Big Changes Merged This Week For The Linux 4.17 Kernel

[phoronix]

Phoronix: The Big Changes Merged This Week For The Linux 4.17 Kernel

We are now through the first week of the two week long Linux 4.17 kernel merge window process for introducing the new features/functionality to this next big kernel release...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.17-Week-One-Features

[tildearrow]

Typo:

- Thunberbolt USB/SL4 security level support

[schmidtbag]

I feel like any time there is a CPU architecture being removed from the kernel, that should warrant a new kernel version. To me, that'd make a lot more sense than the arbitrary numbering scheme used now. Also, if an all-new achitecture were made, that should also warrant a new kernel version.

[lucrus]

I feel like kernel versioning should use codenames like "nt, millenium, xp, vista, 10pro, mavericks, yosemite, el capitan, high sierra" and so on: many people would feel at home...

[fallacy]

Still no Wireguard

[starshipeleven]

I feel like any time there is a CPU architecture being removed from the kernel, that should warrant a new kernel version. To me, that'd make a lot more sense than the arbitrary numbering scheme used now. Also, if an all-new achitecture were made, that should also warrant a new kernel version.

Why a change in CPU support would warrant a new kernel version? It's not like any of the supported CPUs use mainline kernel anyway, apart from some x86 and some ARM devices run by enthusiasts, the bulk of stuff running Linux is using some random older version from its manudacturer's SDK or from commercial distros like RHEL.

[schmidtbag]

Why a change in CPU support would warrant a new kernel version? It's not like any of the supported CPUs use mainline kernel anyway, apart from some x86 and some ARM devices run by enthusiasts, the bulk of stuff running Linux is using some random older version from its manudacturer's SDK or from commercial distros like RHEL.

I understand your point and considered that myself, but think of it like this: the CPU architecture is the core point of interest in the kernel. It determines whether or not you can even run the OS on whatever platform it is you're trying to use. So, for example back when i386 was dropped, that would've been a good time to transition to the 4.0 kernel, where you could say "Intel i386 CPUs will work on any Linux kernel below 4.0".
As another example, let's say the 3.0 kernel was released when RISC-V was first released in 2010. That way, you could say "RISC-V works on kernels 3.0 and above".
This is very straight-forward, and relatively easy to keep track of. Architectures are added and removed often enough to keep the numbers fresh.
Meanwhile, architecture removals/additions could be planned around kernel versions. So for example Linus could say "3.7 is too early to switch up, let's hold of i386 a little while longer". This way, maybe there could've been many major changes planned around the 4.0 release, making the upgrade more significant than it actually was.

There's not really anything else to base the kernel on, and I'd say revolving it around CPU compatibility is a better idea than "let's change the number because Linus feels like it". Everything else is either linked to the CPU architecture (like northbridges), irrelevant (like 1980s peripherals), non-crucial (like sound cards), or doesn't have to depend on the mainline kernel to function (like GPU drivers).

[-MacNuke-]

So, for example back when i386 was dropped, that would've been a good time to transition to the 4.0 kernel, where you could say "Intel i386 CPUs will work on any Linux kernel below 4.0".

That would be just more work with no benefits. It's not like that Linux drops CPU architectures just because they feel like it. They get dropped because nobody uses them anymore. Show me one user that used a vanilla 4.x kernel on a 386. There are also no users of kernel 4.16 on a POWER4 because it did not work for years.

Orienting kernel version numbers around ancient architectures would be just stupid. Nobody "suffers" from those changes.

[xpue]

codenames

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile#n6

NAME = Fearless Coyote

[lucrus]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile#n6

I know, but there are a number of issues with the current naming scheme:

• It's Fearless Coyote since 4.11 - so it does not match important changes in supported architectures, nor in other areas (Meltdown mitigation, amdgpu, ...)
• It's reminescent of Ubuntu releases, and that's bad of its own ("Psychotic Stoned Sheep", "Roaring Lionus", "Fearless Coyote", "Bionic Beaver", same nonsense, you get the picture)
• Currently no one really cares about the name, just because it's a random name, just like it's a random version number. Remembering what kernel supported what is a nightmare.
• I recall in past years I found it handy to know that 2.4+ meant iptables support, while 2.2 meant ipchains and 2.0 meant ipfw or something like that. If being constrained by version numbers gets in Linus way, at least giving a "commercial" name to each "important" release would be nice.
• I know, Linus does not give a f*** to commercial issues, so I'm going to take care of that in his place. I'm going to call Linux 4.17 "Manhood" 'cause you know, it will be a great release... I'm sure it will be easy to remember for everyone...