on disabling drivers that use non-Free firmware

[Alexandre Oliva]

On Jan 24, 2009, Richard M Stallman <rms at gnu.org> wrote:

>     Removing all the code in a driver, rather than simply disabling its
>     requests for non-Free firmware, creates another major burden: any patch
>     that touches files in that driver becomes an additional maintenance
>     burden.

> I don't see why.  Would you explain?

Here's the scenario that triggers the problem for me.

I'm trying the Fedora CVS repository to build Linux-libre packages.

The binaries are built following this procedure:

- unpacking a source tarball (say, linux-2.6.28.tar.bz2), downloaded
from upstream and verified with digital signatures.  I modify this so
that it downloads say linux-2.6.28-libre.tar.bz2 from our servers.

- applying patches distributed by upstream to bring it up to minor
releases (2.6.28.1) or to pre-releases of the next release (2.6.29-rc2,
2.6.29-rc2-git1).  These days, most of the time, no changes are needed
in the update patches, and changes to the pre-release patches are mostly
limited to the moving about of firwmare files while Linux completes the
transition to the request_firmware() API.  When changes are needed, I
arrange for the modified patches with '-libre' in the name to be
downloaded from our servers.

- applying several other patches that are available directly from the
CVS repository.  Some are created within the Fedora community to adjust
the kernel for Fedora; some bring in fixes and improvements from various
development trees.  Most of them don't require any changes, but there
are a few that often require attention.  For example, the patches from
the Linux wireless community often includes changes for firmware in
certain key drivers, and nearly always modify the drivers that use such
firwmare.  Video Direct Rendering drivers at times requires changes
because e.g. nouveau contains blobs, but sometimes they need tweaking
for silly reasons such as Kconfig conflicts because the 'depends on
NONFREE' marks are not present in the context in the patch.

Any patch that fails to apply is proportionally a major burden.  The
reason I can maintain Linux-libre is that, most of the time, it takes me
just a couple of minutes a day to keep up with upstream.  If a patch
fails to apply and requires manual intervention, this couple of minutes
at the very least doubles (the bulk of the manual operation has to be
repeated after fixing the error), and, when I need to tweak patches so
that they apply, this may translate into tens of minutes and, in rare
cases, even hours.


Now, I'm not the only one affected by patch conflicts.  I've seen others
who wanted to build Linux-libre plus patches run into problems and even
give up because of simple patch conflicts.  That's an undesirable
outcome.

This improved when we switched from the original 'remove everything'
approach taken by gNewSense at first, to the 'remove just the blobs'
approach I introduced later.  However, the Kconfig markers still cause
errors when applying patches for unrelated features that happen to
appear close enough in Kconfig for the absence of markers to cause a
patch to misapply.

This convinced me that it's important to minimize divergence.  It's very
convenient for me and for our users, and, as long as every portion,
reference and allusion to non-Free firmware is removed, it shouldn't
make any different in terms of ethics and morals.

> When a patch tries to change a file which is not present, that part
> of the patch will be ignored, right?

patch will report and error, ask questions and confuse users.  Besides
that, removal of files requires changes to other files that are not
removed, which in turn creates other patch conflicts that might be more
difficult to address.

-- 
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