Six Great Features with the Upcoming Linux 6.6 Kernel
1–10 of 40 posts
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#2[deleted]
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#3Off 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?
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#4Off 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?
> Wouldn't it be cleaner, easier and simpler to keep those separate and add them later as "modules"?
That is exactly what Linux does. Part of building a Linux distribution is determining which modules to ship by default to your users. To the best of my knowledge, the overwhelming majority of drivers are not installed by default, and the average user will never need them.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#5Off 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.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#6Off 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?
You're literally describing something like macOS/iOS which is based around a microkernel (XNU, based on Mach). See also QNX for a non-unix OS that does this.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#7Off 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?
As another comment explains - the vast majority of drivers are not compiled as part of a standard Linux distribution.
If you're asking why so many drivers are included in Linux's mainline repository and not maintained off-tree - the major advantage of being upstreamed is that changes to the kernel have to take your driver into account as well. e.g. anyone who changes any APIs will have to update your driver as well.
Moreover, being upstreamed certifies that your driver has gone through a non-trivial review process to be merged into the mainline and is an indication of quality/stability.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#8Off 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?
> Wouldn't it be cleaner, easier and simpler to keep those separate and add them later as "modules"? That is exactly what Linux does. Part of building a Linux distribution is determining which modules to ship by default to your users. To the best of my knowledge, the overwhelming majority of drivers are not installed by default, and the average user will never need them.
I think that by 'module' they were thinking of user-space drivers rather than kernel modules.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#9Off 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.
Theoretically the monolithic approach is supposed to be more performant. Abstracting away everything into modules can be more stable, but also usually incurs some overhead. But this is holy war territory and I'm trying to ELI5 best as I can.
Re: Six Great Features with the Upcoming Linux 6.6 Kernel
#10Off 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 old modules to the new kernel.
The reasons for module breakage may be just the movement of some definitions from one header to another, which break compiling, but most frequently some structures gain new members or lose old members, or some functions gain new arguments or lose old arguments.
When there are new members or arguments it is hard to discover what values should be put in them, while when members or arguments are deleted it is hard to discover whether their absence must be compensated somehow, e.g. by inserting invocations to other functions.
In the worst case everything can be solved by reading the kernel source, but that takes a lot of time and those who maintain out-of-kernel modules usually do not do this as a full-time job, so they do not have time to scan every day the kernel mail lists, to see if anyone has plans to make changes that will break their modules.