SoylentNews is people
SoylentNews
This kernel is simply huge: there is so many new and improved features with this particular release that it's mind-boggling. I'm having difficulty remembering such a time a kernel release was so large.
The quick summary of Linux 5.6 changes include: WireGuard, USB4, open-source NVIDIA RTX 2000 series support, AMD Pollock enablement, lots of new hardware support, a lot of file-system / storage work, multi-path TCP bits are finally going mainline, Year 2038 work beginning to wrap-up for 32-bit systems, the new AMD TEE driver for tapping the Secure Processor, the first signs of AMD Zen 3, better AMD Zen/Zen2 thermal and power reporting under Linux, at long last having an in-kernel SATA drive temperature for HWMON, and a lot of other kernel infrastructure improvements.
(Score: 5, Insightful) by DannyB on Monday February 10 2020, @08:12PM (16 children)
Isn't the kernel modular?
Now the last time I read about this, and compiling kernels, was in about 1997 as I was studying Linux. In June 1999 I finally got my first Linux box and never looked back.
As I understood things at that time, kernel modules could be omitted, compiled into the kernel, or compiled as loadable modules.
1. Omitted -- probably because they are irrelevant. Hardware modules for hardware you don't have. Etc.
2. Compiled in to kernel -- because you want them at boot time even before the ramdisk is available.
3. loadable modules -- because you might want them, and can make them packages so that you could possibly omit installing them, but with a package manager could load them if software needing those modules depends on them. Contrived examples: VPN, certain hardware support, WiFi, certain filesystems, etc.
If you're needing a kernel for a small system like a Raspberry Pi, isn't it possible to build a modular kernel, and leave most of the modules off of the distribution image? Letting those modules be "installed", then at runtime "loaded" as needed?
Or am I misunderstanding something?
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Monday February 10 2020, @09:41PM (12 children)
Sure. Much like Windows you install drivers for devices you attach vs. pre-installed drivers.
Its really a balancing game, pre-installed so stuff just works right out of the box for various scenarios vs. the basic stuff mostly works, for all others the users have to go "configure" (in the case of linux) or install drivers (in the case of windows).
For majority of folks, the non-geeks, I'd assume the former is preferable. For the geeks, obviously the former is an affront to architecture purity due to the "bloat" and the rest of the world should follow their shining light.
(Score: 2) by DannyB on Monday February 10 2020, @11:00PM (11 children)
It would seem to me that having all of the kernel modules available on disk has no significant penalty. It merely costs disk space. Nothing more. If you plug in a new hardware item, you already have a driver immediately ready to use. That's convenience. Or alternately, go through a Windows-like experience of "searching for driver . . ."
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 4, Insightful) by Runaway1956 on Tuesday February 11 2020, @01:37AM (5 children)
That "searching for driver" experience is vastly different on Linx, vs Windows. Mostly, the drivers are found via the package manager, whether it be RPM or APT or whatever. On Windows, if you don't have an installation disk, then you go to Google. Google doesn't mark the results with tags like "reputable source" or anything. Unless you know what you are doing, you can easily download a boatload of malware, and install it, instead of the driver you were searching for. Alternatively, you can find an outdated driver, which may or may not work for your particular hardware.
Both worlds have their problems, but I think Linux problems are a lot easier to solve reliably than Windows.
(Score: 0) by Anonymous Coward on Tuesday February 11 2020, @06:28AM (4 children)
I wish they would just compile statically. Give up on the dream of upgrading each package separately. Huge, static globs of binary for each program you use that I can run off a USB. That is actually my idea of perfection in software - it never breaks after upgrade. You can run off a USB stick. It never breaks(*).
(*) Shut up.
(Score: 2) by DannyB on Tuesday February 11 2020, @02:40PM (3 children)
Maybe another alternative . . .
Maybe it is time that Kernel developers consider the possibility of . . . OMG . . . having a standard kernel driver API. Not for all possible kernel modules, but for device drivers. It seems device drivers are the vast majority of kernel source code, or so I am under the impression. If necessary later, introduce a 2nd improved kernel driver API. Surely enough is understood about what kernel access a device driver needs after about 30 years?
Another idea, multiple standard interfaces for different kinds of drivers. Eg, filesystems. Direct memory access drivers. Video devices. Etc. A single driver could implement one or more of these interfaces.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:52AM (2 children)
from the executive summary of https://www.kernel.org/doc/html/v4.14/process/stable-api-nonsense.html [kernel.org]
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:56AM
Should have linked this version https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html [kernel.org] or https://www.kernel.org/doc/html/v5.6-rc1/process/stable-api-nonsense.html [kernel.org]
(Score: 2) by DannyB on Wednesday February 12 2020, @08:44PM
I can't, or don't, or shouldn't have a strong opinion on this. I don't write kernel modules. So I'll defer to those who do. Thanks for the info.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2, Informative) by The Mighty Buzzard on Tuesday February 11 2020, @04:20AM (3 children)
Having the necessary functionality for a specific module to even hook into does cause very significant overhead. Having a specific SATA driver, for instance, built as a module is not the same as not even having SATA support in the kernel. If you know you're never going to need any hardware but what you currently have, you can shrink the complete fuck out of the kernel.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Tuesday February 11 2020, @02:45PM
That is another useful thing about the kernel, its adaptability for small devices with fixed hardware. Wristwatches. Cameras. RoKu, TiVo. Thermostats. And who knows what else.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by DannyB on Tuesday February 11 2020, @10:36PM (1 child)
That makes sense. Having support for the module in the kernel is a non-zero cost, in addition to disk cost of the module.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @02:45AM
Not to mention that some modules and CONFIGs are mutually exclusive.
(Score: 2) by RS3 on Tuesday February 11 2020, @06:42PM
In fact it's probably net zero. It's about the same size as a module or compiled into the kernel.
You could argue that the kernel usually resides in a separate partition than /lib, but either way, kernel modules are pretty small.
(Score: 2) by digitalaudiorock on Monday February 10 2020, @10:23PM (1 child)
Absolutely. This machine (very old hardware) is running Gentoo and a 4.19.97 kernel, with everything I need, and pretty much nothing more, compiled directly into the kernel with the exception of a few modules:
The only thing that's huge is the (mostly unused) source:
(Score: 2) by The Mighty Buzzard on Tuesday February 11 2020, @04:22AM
I used to do that too. Until about the three bazillionth time I had to rebuild the kernel because I wanted to plug something in that I hadn't built the driver in for. It's just not worth doing on a desktop/laptop.
My rights don't end where your fear begins.
(Score: 2) by hendrikboom on Tuesday February 11 2020, @12:58AM
What you need is enough drivers compiled in to be able to access the hardware and file systems containing the modules.