Hi Steven, I'm glad you brought this up... please bear with my reordering of your reply, which makes it easier to make my point:
On 24/12/2013 14:33, Steven Chamberlain wrote: > I seem to think the patch to the Xorg driver (#732514) is the riskiest > change, at which point radeon will stop working. Well, up to this point autoloading was not operative, in part due to #732514 but also due to missing linker.hints in kernel (#684595). Fixing both these bugs means the kernel will attempt to satisfy userland's demands of a fully working "radeonkms.ko" module. Since we don't provide that, this situation has the potential of exposing new bugs. But I don't think relying on bugs to mitigate the risk is necessary. Fixing them puts the kernel in control, and then there are many other ways to achieve the same thing. Note that only when userland meets these two conditions: 1- Is able to load "radeonkms" module. 2- Is able to detect modesetting sysctls after loading the module. then it will expect working KMS support. However, it is up to the kernel wether each condition is met: 1- The kernel build system still builds "radeonkms" even if the firmware was disabled. 2- The radeonkms module still enables the sysctls even if firmware load failed. My proposal was to disable #1 (i.e. remove the module). However if the module is still useful there are many ways in which #2 can be changed to adhere to our needs. For example, we could disable the sysctls every time firmware load failed, or we could include a whitelist of drivers which still work despite that. Or we could use a blacklist instead, and enable the sysctls unless firmware failed _and_ the driver is known to generate trouble without it. We can really fine-tune to any level we want. The only limit is the time required to implement and test, debug, etc. > If we're not doing any automatic module loading yet, I don't think there > will be any functional change from doing this? It would preserve the status quo, since the same upload was targeted to fix #684595 (linker.hints bug). However if we need more time to make a decision, we could just postpone the fix for #684595 just to get -RC3 out of the door without delay. >> Is there a case for providing an incomplete version (i.e. without firmware)? > > It has the capability to load firmware, though. So it potentially > allows for packaging just the microcode, just as firmware-linux-nonfree > does for Radeon KMS on Linux. Well no, not really. I've seen previous discussion assuming this is the case, but in fact the firmware_* interfaces don't implement anything similar, and upstream favours embedding firmware in dedicated modules (e.g. radeonkmsfw). They even have support in the build system to handle this in the least painful way (see sys/modules/drm2/radeonkmsfw/*/Makefile for an example). It is difficult for us to make a case to upstream that the "Linux way" is better. I already persuaded them to provide the choice in build system on whether to provide sourceless firmware or not (this resulted in -DWITHOUT_SOURCELESS make knob which has been tremendously helpful to reducing the sys/modules/Makefile delta). What do they gain by moving the blobs off *fw modules? AFAICS, they're just losing the features provided by the module linker (e.g. versioned dependencies). > I hope I will have some time now to test this, Sure. Since this matter is quite complicated, and probably needs a lot more careful thought and testing, how about we just preserve the status quo in -RC3 upload by putting #684595 on hold? Then #732514 has no effect (except to kfreebsd-downloader users, which is fine IMHO), and we have time to think this through. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
