On Dec 27, 2010, Richard Stallman <r...@gnu.org> wrote: > The proposal above would still show the name of the firmware programs in > source code. I'm not sure they have to be mangled or removed from the > sources, because sources are, in a way, passive. I was focused on > fixing the problem of actively recommending non-Free Software through > request_firmware.
> I am not 100% convinced I agree, but I don't see a specific reason to > disagree, so I agree tentatively. My reasonsing was that firmware filenames are static identifiers. Even if we mangled them, they'd still be identifiers to the same files, and web pages would quickly pop up mapping the identifiers to the file names, so it seemed pointless to try to disguise the sources. I hadn't considered the possibility of generating different manglings in the sources for each release of Linux-libre, but now that it occurred to me, it seems excessive, and still prone to third-party documentation that provides the reverse mapping, rendering the mangling useless. So I figured run-time mangling, that can vary not only from release to release, but also from build to build, even from session to session, was far more important. > Per the idea above, if the kernel is not told that a certain piece of > firmware is available, it won't issue requests for it, and it will only > report an error that firmware is missing: same as currently, minus the > unsatisfyable request for a "/*(DEBLOBBED)*/" firmware file. > Does "currently" mean "in the current version of Linux Libre"? Yep. > There is something here I don't follow. I see two separate technical > questions, and I don't see how they relate. > 1. How and when Linux gets the list of firmware programs installed. > It could get this list by reading a directory, or some other way. > It could get this list once at startup, or it could check again > whenever it wants a firmware program. Currently, it doesn't. There's no way for it to even tell where the userland hotplug program will look for firmware files, or how it will map the requested identifiers to file names, or how it will respond. Say, it would be perfectly possible for a hotplug program to read the identifier from the /sys/firmware/... pseudo-file, look it up in a database, get the corresponding BLOB (database speak for large binary object, not to be confused with non-Free firmware in binary form), and cat it to the corresponding /sys/firmware/... pseudo-file, or signal through another (?) /sys/firmware/... pseudo-file that the request cannot be satisfied. The lack of an interface to inform Linux what pieces of firmware are installed is what IMHO makes Linux induce users to install non-Free firmware: since it can't tell whether firmware is installed, it has to ask for it, and once it gets a reply that it's not there, it will have induced the user to install it, because the request will have been logged. By adding an interface to tell the kernel the list of currently available firmware files, we can get the kernel to refrain from asking for (non-Free?) firmware that's not installed, which could even obviate the need for identifier mangling. > 2. What it says when the firmware program is not available. The kernel logs the request, including the identifier, and, when it fails, the module that issued the request often logs an error message, that usually includes the firmware name. Also, the kernel sends the firmware name/identifier to the userland hotplug program, and that program can do pretty much whatever it likes with the name, including looking up the name in package repositories, suggesting users to install the package that provides the firmware, or even install it behind their backs. In Linux-libre, we mangle the firmware name both in the request and the error message, so there's no chance that any of this may happen. However, this also disables any possibility of using non-Free firmware that the user has installed and would like to use. > To me, these two questions seem independent. You seem to be saying > that a change in (1) would affect (2), but I don't see how that is so. They are independent, indeed. I'm trying to address the problem that the kernel actively requests non-Free firmware, by informing Linux in advance about the available pieces of firmware. The logged error messages are a much simpler problem to deal with. “device: Missing Free firmware” is a good replacement message IMHO, and that's what we currently output. > Could you explain? Was this clear enough? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer