this post was submitted on 17 Sep 2024
88 points (100.0% liked)
Linux
4962 readers
340 users here now
A community for everything relating to the linux operating system
Also check out !linux_memes@programming.dev
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Monolithic kernels and drivers are an issue.
I understand why its easy, but on Fedora Atomic I even have all the userspace drivers for intel, amd, nvidia and maybe more, even though I clearly just use intel...
The problem is not caused by mono kernel. Just because AMDGPU driver was developed in mono style. i.e. they include the code of all generations in one driver. In monolithic kernel, the developer can develop drivers with "micro" style. e.g. Intel's GPU driver doesn't use mono style, they created a new driver when they changed GPU hardware architecture.
Monolithic kernel is a concept about address space. If all parts of a kernel are running in the same address space, this is a monolithic kernel, otherwise it's a micro kernel.
This problem is about how to split parts, but not how to place parts in memory.
Thanks for the insight
This is the real issue. This is one area that Windows, despite its historical hardships, handles much better.
(Mac OS too but they killed kexts for the public anyway)
I'd love to see a more dynamic approach (that doesn't rely on DKMS) someday.
I believe the advantage is that old drivers still work as they are all in the kernel. With them sharing much code it's not even that big of a disk space issue. Edit: A more dynamic approach would be great though, especially with this size issue popping up.
In a way it's great that I'm able to replace any part of my system and it just works without me having to make sure the old GPU driver doesn't leave some traces behind–altough while writing this the latter part shouldn't be an issue with Windows auto download and installation of drivers.