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

11–20 of 40 posts

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#11

Post by maccam94 »

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?

The Linux kernel doesn't have a stable ABI. Thus, if a kernel function signature changes, or a subsystem gets refactored, etc, drivers get updated as part of the process. If the drivers lived outside the kernel tree, they would have to be updated separately by their own maintainers. That's less efficient and prone to breakage, so generally driver modules are merged into the kernel tree. Often they can even share code with other hardware devices!

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#12

Post by seanwilson »

adrian_b wrote: post #10
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?

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.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#13

Post by gaganyaan »

adrian_b wrote: post #10
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?

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…

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.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#15

Post by adrian_b »

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.

That is why everybody attempts to push their modules into the kernel source.

Those who cannot do that because their modules are not open source, like NVIDIA, have a lot of work to do for module maintenance.

Nevertheless, there are also open-source modules that cannot be pushed into the kernel because they are for uncommon hardware with few users, and those also require a lot of work for maintenance, so they are frequently abandoned and no longer brought up-to-date, to be compatible with the latest kernels.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#16

Post by rwmj »

chownie wrote: post #5
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?

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 the best outcome.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#17

Post by rwmj »

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.

Coccinelle semantic patching is pretty cool for making systematic changes across the kernel (eg. adding a parameter to the same function everywhere).

https://coccinelle.gitlabpages.inria.fr/website/

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#18

Post by adrian_b »

maccam94 wrote: post #11
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?

The Linux kernel doesn't have a stable ABI. Thus, if a kernel function signature changes, or a subsystem gets refactored, etc, drivers get updated as part of the process. If the drivers lived outside the kernel tree, they would have to be updated separately by their own maintainers. That's less efficient and prone to breakage, so generally driver modules are merged into the kernel tree. Often they can even share code…

Not only there is no stable ABI, but there is no stable API.

When only the ABI changes, a recompilation of all sources is enough.

When the API changes, then programmers must manually edit the sources and change function invocations and data structures, to match the new API.

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#19

Post by lttlrck »

adrian_b wrote: post #10
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?

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…

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?

Re: Six Great Features with the Upcoming Linux 6.6 Kernel

#20

Post by esaym »

lttlrck wrote: post #19
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…

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.
Post reply on HN