Marking DRI1 Drivers As Legacy & "Broken" Being Debated
Earlier this month David Herrmann sent out two kernel patches to hide "legacy" DRM drivers behind a new Kconfig switch and make these DRI1 drivers depend upon the kernel's "BROKEN" option. Not all are happy about these patches.
3dfx Banshee/Voodoo3+, Intel i810, Matrox G200/G400, SiS, VIA, and Savage graphics card code would be hidden a CONFIG_DRM_LEGACY Kconfig option. Herrmann explained, "Lets move forward and hide the remaining DRI1 drivers behind a config option, so we have a central place to disable them all. Furthermore, we can provide a clear warning to anyone enabling them."
In his second patch, he makes the DRM legacy drivers depend upon the kernel's "BROKEN" option. David explained of that, "The legacy DRI1 drivers expose highly broken interfaces to user-space. No modern system should enable them, or you will effectively allow user-space to circumvent most of your kernel security measures. The DRI1 kernel APIs are simply broken. User-space can always use vesafb/efifb/simplefb and friends to get working graphics. Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to be still used (really?), we can easily revert this and figure out a way to move them out of sight (e.g., moving all DRI1 drivers to drivers/gpu/dri1/)."
These patches aren't about dropping the drivers from the kernel at this time, simply marking them as broken/legacy as they haven't been touched by developers in a number of years and they don't fit with modern Linux graphics technologies. However, they will now be hidden from those building the kernel unless they are looking out for these legacy switch and acknowledging the "broken" status.
The patches were received positively by upstream developers earlier this month while now there's a bit of drama over the patches. In user-space, the old Mesa drivers were dropped years ago from the Mesa tree but users can continue to load those old DRI1 drivers on a modern system due to the stable ABI.
Connor Behan who maintains some DRI1 Mesa driver packages still for Arch has come out against it. He commented, "The drivers were removed from mesa and 'you won't have to freeze your kernel or anything' was one of the justifications given at the time for why this wasn't a bad idea. So yes, I have dri1 packages in the Archlinux repos with no plans to drop them. The people who have emailed me about them and filed bugs are probably much less than 1% of the user base but I've never considered that relevant. The point is that hobbyists who want to use old hardware or play with seldomly updated drivers should be able to do this without too many additional hurdles."
Kevin Brace, the lone developer still working on the OpenChrome DDX driver, has also written his thoughts against it with an anti-consumerism rant. He doesn't want to see VIA DRI1 support demoted/dropped unless some experienced developers help in bringing up the OpenChrome DRM/KMS driver and also writing EXA/DRI2 for OpenChrome. Considering how long the VIA open-source code has been rotting away without any interest from the veteran open-source graphics driver developers, that's probably unlikely.
Those interested can continue the thread here.
3dfx Banshee/Voodoo3+, Intel i810, Matrox G200/G400, SiS, VIA, and Savage graphics card code would be hidden a CONFIG_DRM_LEGACY Kconfig option. Herrmann explained, "Lets move forward and hide the remaining DRI1 drivers behind a config option, so we have a central place to disable them all. Furthermore, we can provide a clear warning to anyone enabling them."
In his second patch, he makes the DRM legacy drivers depend upon the kernel's "BROKEN" option. David explained of that, "The legacy DRI1 drivers expose highly broken interfaces to user-space. No modern system should enable them, or you will effectively allow user-space to circumvent most of your kernel security measures. The DRI1 kernel APIs are simply broken. User-space can always use vesafb/efifb/simplefb and friends to get working graphics. Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to be still used (really?), we can easily revert this and figure out a way to move them out of sight (e.g., moving all DRI1 drivers to drivers/gpu/dri1/)."
These patches aren't about dropping the drivers from the kernel at this time, simply marking them as broken/legacy as they haven't been touched by developers in a number of years and they don't fit with modern Linux graphics technologies. However, they will now be hidden from those building the kernel unless they are looking out for these legacy switch and acknowledging the "broken" status.
The patches were received positively by upstream developers earlier this month while now there's a bit of drama over the patches. In user-space, the old Mesa drivers were dropped years ago from the Mesa tree but users can continue to load those old DRI1 drivers on a modern system due to the stable ABI.
Connor Behan who maintains some DRI1 Mesa driver packages still for Arch has come out against it. He commented, "The drivers were removed from mesa and 'you won't have to freeze your kernel or anything' was one of the justifications given at the time for why this wasn't a bad idea. So yes, I have dri1 packages in the Archlinux repos with no plans to drop them. The people who have emailed me about them and filed bugs are probably much less than 1% of the user base but I've never considered that relevant. The point is that hobbyists who want to use old hardware or play with seldomly updated drivers should be able to do this without too many additional hurdles."
Kevin Brace, the lone developer still working on the OpenChrome DDX driver, has also written his thoughts against it with an anti-consumerism rant. He doesn't want to see VIA DRI1 support demoted/dropped unless some experienced developers help in bringing up the OpenChrome DRM/KMS driver and also writing EXA/DRI2 for OpenChrome. Considering how long the VIA open-source code has been rotting away without any interest from the veteran open-source graphics driver developers, that's probably unlikely.
Those interested can continue the thread here.
28 Comments