FSFLA: Linux kernel is "open core"

This just shows that you don't have any idea of what I want.

I believe computers should obey their users. This userspace program you suggest could do nothing but accept or reject software that users have installed on their computers. IMHO, that doesn't make sense. If users chose to install certain software on their computers, the computers had better obey when users command “run it” or “install it”. Anything else is, erhm, defective by design, if you get what I mean.

If you're assuming that myself or Linux-libre have any intention of taking this control away from users, of, like, protecting users from themselves, you'd be wrong, because the assumption is wrong. The goal is rather to help users defend themselves from the luring by unethical vendors that tempt them into giving up control over their computers, giving up freedom and betraying their community; unethical vendors that try to fool them into thinking of it all as ok, even desirable.

Now, you may get as bored and stupid as you wish, and rationalize that a request might be hidden from the user by userland programs, and that ignorant users wouldn't know to look at log files to investigate and troubleshoot why their devices aren't working, and that they wouldn't know to search for the log filename in a web search engine and find the file along with a message that is biased towards accepting it without questioning or even thinking about it. If you assume users wouldn't do that, you'd again be mistaken, because the assumption is wrong.

Now, let's look at your statement that a userland program is in a much better position to do what I want. Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want.

Setting aside this key problem, that you'd surely qualify as irrelevant, I can see how a hotplug program could look at a request from the kernel (or a module's firmware requirements) and decide whether or not to satisfy the request, for firmware files that are installed on the system. But then, why would you want to deny loading of modules that the user installed? That doesn't make sense! It's obvious to me that you're trying to solve a different problem.

It gets even more interesting when you get to a module that is *not* installed. The userland program can't possibly know anything about it, but the developer of the kernel module that asks for it knows everything there is to know. So how can you say that the userland program is at a better position to decide how to inform the user about the problem in a way that makes it clear that the hardware vendor is trying to take her freedom away? That's demonstrably false for precisely the cases that matter, and you state that the one piece of software whose developer holds the relevant knowledge is the wrong place to encode it?!?

Finally, you suggest that some other piece of software even prevents modules from being loaded if their meta-information says they might request some unavailable or undesirable module. That's a terrible suggestion. A number of modules request firmware only for specific variants of the hardware they drive, while other variants work just fine without any firmware. For others, the firmware may provide fixes or additional functionality, but the hardware still works fine (sometimes without loss of functionality) without it. See? It doesn't even begin to make sense! Userland just doesn't *have* the information it takes to make even the sort of decision you want it to make. It's the module that knows what it expects.

Also, you mention licensing information. That's only one of the dimensions of the software freedom problem. A number of blobs are under licenses that qualify as Free Software licenses, but since they are missing source code, they are non-Free. I suspect (but can't prove) that they were provided under such licenses so as to fool kernel developers that have a fixation on license-compatibility issues without realizing that X11-licensed code is only compatible with the GPL when you can offer the corresponding sources also under the GPL. Without it, redistributing the binaries as part of a work licensed (even if partially) under the GPL from a third party amounts to copyright infringement. And that's just one of the ways in which fake contributors to the kernel keep other kernel developers legally hostage, and that shows why knowing licensing information is also insufficient.

What userland has that the module doesn't have is a good way to interact with the user and display useful information. That's why Linux-libre is not the best place for that, but it still conveys to userland the information needed to display a useful message. The /*(DEBLOBBED)*/ firmware name was designed that way so that it never matches a real file, and so that hotplug scripts can match in the slow path and send an informative message to users through a graphical interface. This string also makes to logs, so that users can immediately find out there's something wrong with the blob that's being asked for, when they web-search for this string they found in their logs.

So, your design is pointless for my goals, and even for yours it uses insufficient information, it misses even that at cases that matter, and the proposed improvement breaks it further. All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information. I *will* let you do that, Dave ;-), but since that will do nothing to accomplish my goals, I'll have to keep on doing what needs to be done at the place where it can actually be done. Your shouting and misrepresentation (out of misunderstanding?) of my goals won't change that.