Nearly Half A Million Lines Of New Graphics Driver Code Sent In For Linux 5.19

[phoronix]

Phoronix: Nearly Half A Million Lines Of New Graphics Driver Code Sent In For Linux 5.19

David Airlie this morning sent in the Direct Rendering Manager (DRM) subsystem updates for the Linux 5.19 merge window. Most notable with the DRM display/graphics driver updates for this next kernel version is a lot of work on Intel Arc Graphics DG2/Alchemist in getting that support ready plus initial Raptor Lake enablement. as well as AMD preparing for next-generation CDNA Instinct products and RDNA3 Radeon RX 7000 series graphics cards...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-DRM-Driver-Updates

[uid313]

That is half a million lines of code too much in the kernel.
Imagine if all the device drivers lived outside a little, secure, audited kernel.

[Alexmitter]

That is half a million lines of code too much in the kernel.
Imagine if all the device drivers lived outside a little, secure, audited kernel.

Imagine what a catastrophically bad idea that would be, looking at every micro and hybrid kernel based system out there that has to support a large amount of of the shelf hardware. Nightmare to audit the end product which is the point that matters, a nightmare to keep secure, a nightmare to keep little with various levels of driver support interfaces.

Why can't such a driver live in its own folder inside the kernel tree, well separated from everything else and only loaded into memory when actually needed keeping the actual kernel in memory small, secure and auditable.

[sireangelus]

Imagine what a catastrophically bad idea that would be, looking at every micro and hybrid kernel based system out there that has to support a large amount of of the shelf hardware. Nightmare to audit the end product which is the point that matters, a nightmare to keep secure, a nightmare to keep little with various levels of driver support interfaces.

Why can't such a driver live in its own folder inside the kernel tree, well separated from everything else and only loaded into memory when actually needed keeping the actual kernel in memory small, secure and auditable.

... that is exactly how modules work...

[user1]

That is half a million lines of code too much in the kernel.
Imagine if all the device drivers lived outside a little, secure, audited kernel.

I'm not sure what you mean exactly. If you're referring to a microkernel, then yes, that's the only option because in a microkernel system everything (including device drivers) beyond the bare minimum things required from a kernel, is in user space. (But after the Microkernel hype started in the 80's, we still don't have a general purpose Microkernel OS after 30+ years).
If we're talking about a monolithic / hybrid kernel, then in Linux's case it's a really bad idea. I mean who would want to deal with more out of tree modules that may potentially break with kernel updates?
I would also say even though Windows (which is a hybrid kernel) has a stable driver ABI unlike Linux, the way drivers are distributed on Windows is an utter mess. You have Windows Update, which sometimes installs really outdated drivers, so you need to search, find, download and manually install drivers if you want newer versions. Oh, and Windows Update also tends to automatically overwrite graphics drivers with an older version for some people. It can happen anytime, no matter what you're doing, so it will cause instabilities/crashes as a result. Imo, this is the biggest downside of Windows and it would've been much better if its kernel had something similar like Linux's in-tree drivers because this will fix its driver mess. (But that would probably cause license issues, since all drivers on Windows are proprietary).

[schmidtbag]

One of the nice things about Linux is you can opt in which modules you want to build. The thing is, there could be a way for distros to split up the kernel so you only install what you need, but by default all of them are installed (kind of like how Mesa is handled). In other words, they build the whole kernel with all the bells and whistles but then they split up the files into separate packages as needed. Despite how many lines of code there are, the kernel isn't that big, so, it's not like there would have to be a lot of ways it gets split up.

[mdedetrich]

I would also say even though Windows (which is a hybrid kernel) has a stable driver ABI unlike Linux, the way drivers are distributed on Windows is an utter mess. You have Windows Update, which sometimes installs really outdated drivers, so you need to search, find, download and manually install drivers if you want newer versions. Oh, and Windows Update also tends to automatically overwrite graphics drivers with an older version for some people. It can happen anytime, no matter what you're doing, so it will cause instabilities/crashes as a result. Imo, this is the biggest downside of Windows and it would've been much better if its kernel had something similar like Linux's in-tree drivers because this will fix its driver mess. (But that would probably cause license issues, since all drivers on Windows are proprietary).

On the other hand because of Windows hybrid kernel design the Windows desktop is not a complete and utter shambles from a usability perspective because if you get a new system and/or graphics card you can just go to the vendors website, download the drivers and this will work even on Windows systems that are 10+ years old (currently any Windows OS that supports WDDM which came out when Vista did).

Contrast that to Linux where in other to get good hardware support for new devices you have to use the newest Kernel (doesn't always completely work) which depending on your distro (i.e. non rolling) can be problematic at best and if you use a LTS distro this is pretty much a non option (at least if you care about the S part of LTS). This is not a hypothetical problem, we have had this issue with Linux devices that we use at my work.

Your specific remark about difficulties with which drivers you get is more of a package management problem rather than a hybrid kernel problem. Windows does suck here, but if Linux was hypothetically a hybrid kernel you wouldn't have the problems you describe because that would all be handled by a package manager (with a hybrid kernel your driver would be a package just like any userspace program). In fact this is currently done with DKMS, the obvious problem being that DKMS is only stable for a Linux major version (thats the lack of ABI problem). I mean with my current distro (Manjaro) the NVidia driver is just a package.

[Mangix]

Most of the codesize is autogenerated headers that are effectively dead code anyway.

[mdedetrich]

Imagine what a catastrophically bad idea that would be, looking at every micro and hybrid kernel based system out there that has to support a large amount of of the shelf hardware. Nightmare to audit the end product which is the point that matters, a nightmare to keep secure, a nightmare to keep little with various levels of driver support interfaces.

Sorry to shock you but unless you use something like NixOS (which is already a stretch but lets go with that) the Linux kernel is already a nightmare to audit especially with all of the configuration options it has. Linux being a hybrid kernel wouldn't make it that much worse, and honestly if you are at the point of auditing a kernel, Linux is the wrong one to be using because its a futile exercise.

To put things into perspective, if the Linux kernel was properly audited you wouldn't even have "LTS" distros, instead everyone would be doing rolling release with the release of the kernel taking a while (because it needs to be audited).

And in any case DKMS already throws the "auditable" argument you have out of the window because you can currently load code as a module if you want, its just only stable for specific Kernel versions.

Unless your definition of auditable is "source code being in the same spot where the kernel is" which if so is the dumbest variant of auditable you can come up with.

[user1]

On the other hand because of Windows hybrid kernel design the Windows desktop is not a complete and utter shambles from a usability perspective because if you get a new system and/or graphics card you can just go to the vendors website, download the drivers and this will work even on Windows systems that are 10+ years old (currently any Windows OS that supports WDDM which came out when Vista did).

Contrast that to Linux where in other to get good hardware support for new devices you have to use the newest Kernel which depending on your distro (i.e. non rolling) can be problematic at best and if you use a LTS distro this is pretty much a non option (at least if you care about the S part of LTS). This is not a hypothetical problem, we have had this issue with Linux devices that we use at my work.

Your specific remark about difficulties with which drivers you get is more of a package management problem rather than a hybrid kernel problem. Windows does suck here, but if Linux was hypothetically a hybrid kernel you wouldn't have the problems you describe because that would all be handled by a package manager (with a hybrid kernel your driver would be a package just like any userspace program). In fact this is currently done with DKMS, the obvious problem being that DKMS is only stable for a Linux major version (thats the lack of ABI problem).

I didn't say hybrid kernel is the problem. What I meant was only the way drivers are distributed on Windows (as you said). Btw, what makes you think monolithic and hybrid kernels are different in the way they handle device drivers? Unlike Microkernels, in both monolithic and hybrid kernels, device drivers work in kernel space. The only differences between Windows and Linux is the in-tree drivers which Windows lacks and the Stable ABI which Linux lacks. And the fact that you need to have the newest Linux kernel to support new devices is solely because Linux lacks a stable ABI. It has nothing to do with the kernel design (hybrid or monolithic).