A Look At The New Features Of The Linux 4.4 Kernel

[phoronix]

Phoronix: A Look At The New Features Of The Linux 4.4 Kernel

If all goes according to plan, the Linux 4.4 kernel merge window will end today with the release of the 4.4-rc1 kernel. As all of the major subsystem updates have already landed for Linux 4.4, here's my usual look at the highlights for this kernel cycle.

http://www.phoronix.com/vr.php?view=22405

[plonoma]

The link in the article for x86 Assembly code continues to be rewritten in C does not work.

[Daktyl198]

I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.

Thus, I don't really get the point of limiting driver releases with kernel releases. The same way I don't get the point of limiting graphics driver releases with the version of Mesa. Mesa is/was just an OpenGL library. The drivers use the library, not the other way around... so why does the library get to have all the power?

In this regard, Windows is way ahead of Linux. I shouldn't have to upgrade to a new kernel just to fix that pesky audio/networking/etc bug in my driver, wait for somebody to backport it to my kernel, or build the kernel myself. I should just be able to upgrade the driver.

[plonoma]

@Daktyl198
Good points. How Linux handles distribution of drivers is one of many issues Linux has.

Two big issues holding Linux back are handling platform support due to many smaller but compounding issues including legacy x86 code (ARM device tree is a shitty approach the damn thing is growing in size with every new board/SoC/configuration, disaster in the making) and
software distribution/installation ( walled gardens of distro specific app packaging formats and
incompatible package managers )

Not to mention the problems with OpenGL header file and drivers on which you comment touches upon.
This is a symptom of a bigger problem in Linux. Namely not having a good way to request, offer an API. Relying on header files is not a good solution. There should be a system not relying on headers.
How are things done on Windows? Due to OpenGL being available but Microsoft doesn't like to support OpenGL there seems to be a way to support API's without much if any specific OS vendor support.
Maybe avoiding name colisions could be done like how file formats are done but for API's and handles programs/drivers/devices. Drivers should have a way to specify which API, standard(s) they support by name and some metadata. Good identifiers, candidates for metadata wouldbe what organization makes the API and what is the official name of the API under standard organizations such as ISO/ECMA/others (<- extra information is used to avoid name collision, not many organizations would bring out two different API's under the exact same name).

https://en.wikipedia.org/wiki/Standards_organization

https://en.wikipedia.org/wiki/List_o..._organisations
Of course a solution that doesn't require extra OS vendor code/cooperation would be superior and more desirable.

The aforementioned issues are not an exhaustive list.
Among many other issues, here is an example of one issue to be solved in Linux:

https://en.wikipedia.org/wiki/Richacls

Allowing for better access control lists. And operable without data loss / losing more advanced features with Windows ACLs

Windows really is light-years ahead in some aspects of computing.

To be fair to Linux. Packaging drivers with the kernel might have to do with the driver API's changing a lot. Making things difficult for non included drivers to be fixed. The shifting landscape not being conductive to having working drivers stay working for long outside the kernel tree/upstream.

But despite all these issues don't despair people, Linux is getting better.
Check out these two horrors from the past:

There used to be a manually specified boot order for programs on starting up your Linux system.
Basically package maintainers had to organize with every other relevant package maintainer and prepare a boot order manually!
https://wiki.debian.org/LSBInitScrip...dencyBasedBoot
Not to mention the mega driver nonsense that propped up a long time ago
(linked article written on 30 September 2013):
http://www.phoronix.com/scan.php?pag...tem&px=MTQ3Mzc

Eric proposed Mesa Drivers For Mesa at the beginning of August as a way to (slightly) boost performance by bundling all of the Mesa/Gallium3D drivers into a single .so shared library so that link-time optimizations could be applied to them as a whole by the compiler. Additionally, this method can save disk space and has some other benefits too.

[nils_]

I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.

Well actually a lot of things can be built as modules, most distributions will even have the file systems, raid etc. code as modules. However it's impractical to switch out the module while the system is running - you can't rmmod a driver that is in use, so upgrading modules aside from the kernel, while possible, will still require a reboot anyways.

[Daktyl198]

Well actually a lot of things can be built as modules, most distributions will even have the file systems, raid etc. code as modules. However it's impractical to switch out the module while the system is running - you can't rmmod a driver that is in use, so upgrading modules aside from the kernel, while possible, will still require a reboot anyways.

... So? Who cares about a reboot. I'm talking about software releases. I shouldn't have to wait for a new kernel to fix a simple bug in an audio/network/etc driver that was patched just after the current stable kernel dropped.

And no, I'm not going to compile my own. I don't use Linux to spend 10 minutes compiling a kernel every time I want a bug fixed in a semi-timely manner... and without possibly breaking OTHER drivers. Most of us has run into the "my X hardware doesn't work without Y kernel, but Y kernel breaks my Z hardware!" issue and it's fucking ridiculous.

[pal666]

I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.

garbage in - garbage out

https://github.com/torvalds/linux/blob/master/Documentation/stable_api_nonsense.txt

[pal666]

I shouldn't have to wait for a new kernel to fix a simple bug in an audio/network/etc driver that was patched just after the current stable kernel dropped.

don't wait then, install git current

[F1esDgSdUTYpm0iy]

Windows really is light-years ahead in some aspects of computing.

And, conversely, also aeons behind in other areas. Security, performance (just switching from Windows to Linux saw everything I do with this PC perform better, including but not limited to, ironically, Windows native applications (either .NET apps, using Mono or just true native and run via Wine). I'll grant you though that the Linux field is hopelessly divided. Everyone and their dog is able (and sometimes it actually feels like actively engaging in) to release their own distro.

Personally, I have no idea how to fix Linux though. In reality, I suspect it will remain as divided. Heck, look at systemd, it has people once again either following it with a passion or avoiding it like the plague. Even less coherence in the Linux world now.

[nanonyme]

garbage in - garbage out
https://github.com/torvalds/linux/bl...i_nonsense.txt

Right, the good old kernelspace drivers vs userspace drivers split. I guess the moral of the story is don't keep more of your driver stack in kernelspace than necessary and have it be GPL. Write stable interfaces to write userspace drivers against. Graphics drivers just happen to be annoying in the sense that necessary actually means quite a lot