|| ||Alexandre Oliva <lxoliva-3d8yaqT+vUfYtjvyW6yDsg-AT-public.gmane.org> |
|| ||rms-mXXj517/zsQ-AT-public.gmane.org |
|| ||Re: The "Free" Kernel In Debian Squeeze |
|| ||Wed, 29 Dec 2010 07:29:51 -0200|
|| ||johns-mXXj517/zsQ-AT-public.gmane.org, gnu-linux-libre-qX2TKyscuCcdnm+yROfE0A-AT-public.gmane.org|
|| ||Article, Thread
On Dec 27, 2010, Richard Stallman <rms-mXXj517/zsQ@public.gmane.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
> 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"?
> 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
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
to post comments)