Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Six Great Features with the Upcoming Linux 6.6 Kernel

phoronix.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#31

Post by mcny »

skitter wrote: post #23
esaym wrote: post #20

Earlier quoted context omitted.

I don't know the exact rule, but "abstraction layers" for a driver are disallowed. I believe it was AMD or ATI that added a new driver for a device, but they basically just took the code from their proprietary driver, and then put an "abstraction layer" in the middle. That did not make the kernel overlords happy and that version of the code was never merged.

Are abstraction layers still disallowed if they are only able to load GPL code?

> Are abstraction layers still disallowed if they are only able to load GPL code?

How would you possibly implement this as a technical restriction?

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#32

Post by 0cf8612b2e1e »

esaym wrote: post #20
lttlrck wrote: post #19

Earlier quoted context omitted.

Maybe it's untenable, counterproductive or simply a bad idea :-) But has there ever been any attempt to create an abstraction layer in the kernel that does provide a stable ABI? Something that could be used for certain classes of driver?

I don't know the exact rule, but "abstraction layers" for a driver are disallowed. I believe it was AMD or ATI that added a new driver for a device, but they basically just took the code from their proprietary driver, and then put an "abstraction layer" in the middle. That did not make the kernel overlords happy and that version of the code was never merged.

Isn’t that effectively what NVidia does anyway? Some minimal shim that lets their blob do all of the work?

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#33

Post by nuancebydefault »

rwmj wrote: post #16
chownie wrote: post #5

Earlier quoted context omitted.

There's upsides and downsides to both approaches. I think that Linux kernel maintainers continue this approach because this forces driver maintainers to meet a minimum level of effort to get their work merged.

One serious downside (for end users) of having a stable driver ABI would be that manufacturers would release a binary blob driver for their hardware which just about works, but no bug could ever be fixed. Manufacturers wouldn't have any incentive to fix bugs and kernel developers couldn't do it either. The situation of GPL'd drivers in a kernel with an unstable ABI wasn't really planned, but for users it's probably t…

I always thought that ABI was the interface between CPU and executable code, ie the spec of the assembly language for a CPU architecture: aarch64, x86 etc. I now would guess it is also a term used for the interface between libraries (kernel/driver) as long as they are binary (without the source code or headers) ?

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#34

Post by gdprrrr »

nuancebydefault wrote: post #33
rwmj wrote: post #16

Earlier quoted context omitted.

One serious downside (for end users) of having a stable driver ABI would be that manufacturers would release a binary blob driver for their hardware which just about works, but no bug could ever be fixed. Manufacturers wouldn't have any incentive to fix bugs and kernel developers couldn't do it either. The situation of GPL'd drivers in a kernel with an unstable ABI wasn't really planned, but for users it's probably t…

I always thought that ABI was the interface between CPU and executable code, ie the spec of the assembly language for a CPU architecture: aarch64, x86 etc. I now would guess it is also a term used for the interface between libraries (kernel/driver) as long as they are binary (without the source code or headers) ?

It's also used for programming languages like Rust and Haskell. The Rust compiler not having a stable ABI means the way the compiler stores information about function signatures, debug symbols etc in libraries may change between compiler versions, so you have to recompile all libraries.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#35

Post by Nextgrid »

candiodari wrote: post #27
gaganyaan wrote: post #13

Earlier quoted context omitted.

A knock-on effect of this is that it's easiest to get the drivers into the mainline kernel, where you have to license your code as GPL. I'm not sure that that's intentional, but it does help make source code available for more drivers. A stable ABI would likely see many abandonware driver blobs.

That's 100% intentional. In any case, non-GPL modules cannot be upstreamed (except with a license that is compatible with the GPL, e.g. BSD is okay), and cannot touch a lot of parts of the kernel. Also, loading a non-GPL module "taints" your kernel (this cannot be undone except through reboot) and tells everyone on the support mailinglists that you've loaded proprietary code. https://git.kernel.org/pub/scm/linux/kern…

> cannot touch a lot of parts of the kernel

Ironically, this is a form of DRM.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#36

Post by someplaceguy »

candiodari wrote: post #27
gaganyaan wrote: post #13

Earlier quoted context omitted.

A knock-on effect of this is that it's easiest to get the drivers into the mainline kernel, where you have to license your code as GPL. I'm not sure that that's intentional, but it does help make source code available for more drivers. A stable ABI would likely see many abandonware driver blobs.

That's 100% intentional. In any case, non-GPL modules cannot be upstreamed (except with a license that is compatible with the GPL, e.g. BSD is okay), and cannot touch a lot of parts of the kernel. Also, loading a non-GPL module "taints" your kernel (this cannot be undone except through reboot) and tells everyone on the support mailinglists that you've loaded proprietary code. https://git.kernel.org/pub/scm/linux/kern…

> Also, loading a non-GPL module "taints" your kernel (this cannot be undone except through reboot) and tells everyone on the support mailinglists that you've loaded proprietary code.

Except that the Linux kernel falsely taints itself with the "proprietary" bit when a module with a non-proprietary, non-GPL compatible license is loaded.

But of course, not being GPL compatible does not necessarily imply that it's proprietary, e.g. the CDDL (as used by ZFS) is a non-GPL compatible, free software license (according to the FSF).

And furthermore, this is documented and intentional.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#37

Post by rwmj »

nuancebydefault wrote: post #33
rwmj wrote: post #16

Earlier quoted context omitted.

One serious downside (for end users) of having a stable driver ABI would be that manufacturers would release a binary blob driver for their hardware which just about works, but no bug could ever be fixed. Manufacturers wouldn't have any incentive to fix bugs and kernel developers couldn't do it either. The situation of GPL'd drivers in a kernel with an unstable ABI wasn't really planned, but for users it's probably t…

I always thought that ABI was the interface between CPU and executable code, ie the spec of the assembly language for a CPU architecture: aarch64, x86 etc. I now would guess it is also a term used for the interface between libraries (kernel/driver) as long as they are binary (without the source code or headers) ?

ABI is just the name for any binary interface between parts of a program, eg in C there is a well-defined and very long term stable ABI for calling and returning from functions: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... https://www.agner.org/optimize/calling_conventions.pdf

If you combine that with a stable set of C function names and parameters, then you could define an ABI for kernel device drivers if you (and the Linux developers) wanted. While it sounds like a good idea, the outcome probably wouldn't be great for users.

Stable ABIs work in other places. For nbdkit we defined a stable ABI for plugins and have maintained it for over 10 years, so a binary plugin written for 10 years old nbdkit can be loaded by modern nbdkit just fine (and we test this too). This was done to encourage proprietary modules, because that helps with our wider goal to make all block devices and formats visible through an open, interoperable protocol (ie. NBD). Implementing this wasn't very easy, since we also want to allow the plugin interface to evolve. It involves a bunch of C macros and careful expansion of C structs so earlier fields remain compatible while later fields add the new features. https://libguestfs.org/nbdkit-plugin.3.html#API-and-ABI-guar... https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0...

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#38

Post by candiodari »

Nextgrid wrote: post #35
candiodari wrote: post #27

Earlier quoted context omitted.

That's 100% intentional. In any case, non-GPL modules cannot be upstreamed (except with a license that is compatible with the GPL, e.g. BSD is okay), and cannot touch a lot of parts of the kernel. Also, loading a non-GPL module "taints" your kernel (this cannot be undone except through reboot) and tells everyone on the support mailinglists that you've loaded proprietary code. https://git.kernel.org/pub/scm/linux/kern…

> cannot touch a lot of parts of the kernel Ironically, this is a form of DRM.

Not, really as a one-line change to the source code can easily change this behavior. In short, you can run proprietary modules easily, on all hardware the real kernel supports. Try it. No harder than a recompile.

You just can't distribute kernels with proprietary modules outside your organisation, and you have to upgrade and support the modules yourself. Which, I'd bet, effectively means Google, Meta, Samsung & Oracle and other behemoths can and do use proprietary modules.

The main complaint is that, say, any kind of small hardware vendor effectively cannot have proprietary modules in the kernel.

And this is generally regarded as a very good thing, a nice way to deal with a very real threat to open source.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#39

Post by phendrenad2 »

ahmedfromtunis wrote: post #3

Off topic, but I had this question for years now: why does the Unix kernel (try to) contain the drivers to every and each device? Wouldn't it be cleaner, easier and simpler to keep those separate and add them later as "modules"? Isn't this how we're supposed to write other types of software? Why is this case different?

Real answer: Because Linux pretty much follows the Unix architecture, and Unix comes from an era where operating system releases were not created for a class of machines, but a specific machine. This design has worked reasonably well on the PC architecture (a class of machines) too, and the pain of adding a stable driver API outweighs the pain of having broken drivers for longer on average.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#40

Post by anelson »

seanwilson wrote: post #12
adrian_b wrote: post #10

Earlier quoted context omitted.

Because the Linux kernel does not have a stable API for modules. The modules included in the kernel are updated whenever the API changes. For the external modules, every time when a new kernel version is released, they may become broken and there is a lot of work to identify how to update the modules, unless one watches the kernel mail lists every day, because there is also no documentation about how to migrate the o…

How does this manage to scale? With even a modest number of drivers, you'd think the maintenance burden would be unreasonably high in terms of needing to have someone available who understands how a set of drivers work, knows how to test them, and keeps them up-to-date.

My company maintains an out-of-tree kernel module for changed block tracking. It requires a full-time Linux driver developer to keep it compiling and working on new kernels.

Our module is GPL FWIW but I doubt it would be accepted into the kernel tree as it is. We need to have a driver developer on staff anyway to support it so it works out okay for us. But if we ever stop maintaining it, it will bitrot quickly and stop working on new kernels.

Post reply on HN