Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote:
> > That doesn't really change the fact that drivers that only work after
> > pointing it at a non-free data block have a non-free dependency, and
> > belong in contrib, though.
>
> The driver operates as designed regardless of what is in the firmware
> array, file, EEPROM, etc. The device does not. For me, the explicit
> interface between peripheral and CPU makes the distinction clear.
"Firmware not found" is operating as designed, but I don't think that
qualifies as the driver being "functional", any more than "cannot open
shared object file: No such file or directory".
If libdvdread3 required libdvdcss, saying "dlopen failed: libdvdcss.so
not found, giving up" if it's missing, it's just as "functional" as the
driver that can't bootstrap any devices without firmware; both are contrib.
Instead, it still works, as long as you're not dealing with encrypted
data--analogous to a driver that works with some hardware (eg. EPROM
devices with the expected version) and not others, and can go in main.
> Drawing the line elsewhere seems to lead to a place where we forbid
> P6/K7/etc.-targeted binaries (optimized programs or CPU-specific
> kernels) from being in main because they require non-free microcode.
There are three general cases: ROM, EPROM and RAM. ROM works on its own,
can't be changed and there's no firmware block; EPROM works on its own[1],
and you can optionally have the firmware on the drive to upload; and RAM
needs the firmware file to work at all.[2] So, there are a few places
where a line can be drawn.
I think that both ROM and EPROM act like hardware, and should be treated
as such, but that the RAM case acts like software--you have to read it
from a file and send it to the device.
My understanding is that the entire purpose of contrib is for this
case: programs that don't do anything useful unless you plug in some
non-free piece.
[1] If a device has an EPROM, but the contents are never usable by the
driver and it always needs to upload a firmware, it's effectively in the
RAM case: the EPROM becomes irrelevant.
[2] I'm overgeneralizing, of course, ignoring cases like "EPROM but flashed
with an incompatible firmware version" (irrelevant here, as long as devices
do exist with the correct version) and "RAM uploaded from the from the driver,
or falling back on ROM" (seems to fall in the EPROM case).
--
Glenn Maynard
Reply to: