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