> i must say though that it did not address what is the actual > behavior preventing the debian kernel from being acceptable,
I thought it did. > why is it not possible to simply change or suppress the error > message printed to the log or to later or periodically scrub the > logs of the naughty bits Because the kernel is not necessarily responsible for all firmware loading. Alexandre mentioned this in: > It's not just about the error messages, it's also about what the > kernel actually requests of the userland helper script or the > filesystem serving /lib/firmware, and how distros might configure > the loader or the filesystem to respond to such requests. Once the kernel has identified that a firmware is needed for something then we've got the problem he mentioned: > When the kernel starts the helper script, it's active telling a > third-party program "get me a copy of the program foo.bin". Being that the userland firmware loading program is a separate program the kernel has no control over what it might do. Absolutely none. It might log the request, which would be separate from the kernel logging, and so even if the kernel's logging functionality were changed in some way it would not have any impact on what this other program is doing. But, of course, it could be even worse than logging. It could, for some examples: * Display dialog boxes "Hey, this thing is missing. Do you to install it?" This would be along the lines of how messages are shown about missing audio/video codecs when you try to play a video. That is probably even worse that logging because it's right up there, in your face. * Automatically download and install it without even asking anything. * Who knows what else. Being that the userland firmware loading program is a program, it could do anything that a program could do. Even things that we aren't currently thinking of. One might be tempted to say "well, the solution, then, is that -- in addition to neutering the kernel's logging functionality -- to this to get rid of the kernel's support for loading firmware from userland, since it can access the file system directly anyway." But that is already reducing the kernel's support for loading firmware, which was part of the original complaint, and doesn't really address the potential things that could happen: Another problem is that /lib/firmware could be treated specially by the distro where any & all of the kernel's attempts to access files there actually succeed even if the files are not there (Alexandre mentioned the possibility that the distro mounts /lib/firmware as a separate file system under FUSE but that would not be the only possible way of doing this), and then proceed to do exactly the same things that were mentioned as being problems with the userland firmware helper. In this case another program is *still* responsible for handling the request and the worse part is that the kernel would probably not even know this. Of course, some might be tempted to say that "OK, the solution, then, is that -- in addition to neutering the kernel's logging functionality and getting rid of the kernel's support for loading firmware from userland, it should only try to load firmware when it's not mounted as a separate file system. Or something." But at point you're starting to reduce the kernel's ability to load firmware even further, which is one of the issues that people have raised, and I don't know that there is a way for the kernel to be able to know the attempt to access the file system will be handled. The fundamental problem is with firmware loading being outsourced to separate programs, regardless of whether the kernel can detect that this is happening or not. It might not even be able to detect it. And the kernel has absolutely no control over what that separate program does after the kernel has made the request via userland or attempted to access it directly via the file system. Of course, FSF-endorsed distros would never do any of these things but Linux-libre is for use by everyone, even those on what Alexandre called "hostile" distros, and all such cases need to be considered and handled. Given all of these possibilities the firmware loading problem may very well be unsolvable. It's at least very difficult, which is why it hasn't happened already.
