on disabling drivers that use non-Free firmware

Alexandre Oliva lxoliva at fsfla.org
Thu Jan 8 18:33:54 UTC 2009


On Jan  5, 2009, Robert Millan <rmh at aybabtu.com> wrote:

> Somewhat related to this:  I've been toying with the idea of writing a
> desktop session daemon, technically similar to Ubuntu's "restricted-manager",
> but with a different purpose:  detect devices that require non-free firmware
> (based on bus id heuristics), and display a message explaining the user why
> these aren't supported, and discouraging him/her from buying hardware from
> this vendor.

What if Linux-libre helped you instead?

I'm toying with the idea of replacing calls to request_firmware(), that
would have requested non-Free firmware, with calls to
notify_about_nonfree_firmware(), that would issue something similar to
(or totally different from) a request for firmware, with enough
information for userland to decode and present to the user an
informative notice about why that device isn't going to work.

This call would *not* give userland an opportunity to actually load any
firwmare, it would be one-way communication.

That, in addition to obfuscation of the non-Free firmware names in the
kernel tree, it would be enough to avoid inducing users to search for or
use such non-Free firmware, it would use the strengths of the kernel to
simplify the process of informing users, and it would slightly bloat the
kernel with modules whose function becomes limited to informing users
through the request_firmware machinery about why they can't do the jobs
they were originally designed to do.

So, a driver that has:

MODULE_FIRMWARE("foobar.fw");

...

  name = "foobar.fw";

  ...
  
  ret = request_firmware (&fw, name, &dev);

would be deblobbed into:

/*(DEBLOBBED)*/;

...

  name = "/*(DEBLOBBED)*/";

  ...
  
  ret = notify_nonfree_firmware (&fw, name, &dev);


and notify_nonfree_firmware would be defined, as a function or as a
macro, that took information from dev and/or extracted information about
the current module through some other means, so as to issue a uevent
that the userland program you mention above could use to inform the user
about the unethical behavior of the hardware vendor, colluded with or,
more often, identical to the firwmare supplier.

I'm probably going to submit notify_nonfree_firmware to upstream Linux,
once it's implemented.  It would make things easier on our side to not
have to patch drivers/base/firmware_class.c or include/linux/firmware.h
in deblob-<kver>, although we'll have to do that for earlier releases
anyway, so even if they decline it, we can keep on maintaining that on
our own.


So now the question is, would this be helpful for your user notifier, or
would it be simpler to simply disable the driver, and deal with it all
in userland, which already has to know about ids for modprobing and
hotplugging anyway?

-- 
Alexandre Oliva           http://www.lsd.ic.unicamp.br/~oliva/
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


More information about the linux-libre mailing list