[EMAIL PROTECTED] wrote: >licenced modules. If we don't want to do that, the most honest way to >handle it is to get another GR out the door,explaining that this is not >easily possible or convenient at this time, and asking for an explicit >exception for kernel firmware. I would second such a GR.
I would be comfortable with a specific exception for *etch only* for drivers which *may need to load in order to mount root*. I would also be comfortable with an exception for *etch only* allowing the *installer* to contain and install such non-free material. I would not be happy with a general exception for the regular kernel packages in 'main'. Rationale for those rules follows; it is based on practical considerations. It would be dangerous to have a permanent exception, because it would just lead to more and more non-free stuff in the kernel -- because it would encourage the people who don't care to avoid fixing it and to reject patches from other people. :-P Observe the foot-dragging on the GFDL issue. It is dishonest to say that it is "not easily possible or convenient" to fix this issue for drivers which don't need to load early, particularly if the installer is exempted; the work for this is quite far advanced. First the issues if the installer is exempted: ---------------------------------------------- For any userspace-firmware-loading driver which does not need to be loaded in order to mount root, it requires only a deb containing the needed file for /lib/firmware (trivial). The kernel firmware loading code and udev/hotplug take care of the rest. For a non-early-loading driver which has embedded firmware, it requires a deb for the driver matching each possible installed kernel (tedious, but certainly feasible, and very straightforward). For a firmware-blob-embedding driver which needs to load before root is mounted, it requires no additions on the installed system, just the debs for the driver module for each possible installed kernel. For a userspace-firmware-loading driver which needs to load before root is mounted, it additionally requires: (1) udev and /lib/udev/firmware.agent available and in the initramfs -- I believe this is being worked on for other reasons anyway, right? (2) patches to yaird/initramfs-tools to install the files from /lib/firmware in the initramfs -- this is easy If these two steps are not ready by freeze time, I would be happy to have an exception for such drivers, as noted above. Second, the issues with the installer -------------------------------------- For any userspace-firmware-loading driver which does not need to be loaded in order to mount the CD or floppy drive, it requires (1) an easy facility for inserting an "extra debs" CD or floppy in the installer (already present) (2) an easy facility for inserting an "extra udebs" CD or floppy in the installer (already present, I think?) (3) a udeb (probably the same one) for each such piece of firmware, which puts the file in /lib/firmware on the installer ramdisk (almost trivial) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) (5) working udev/hotplug & firmware.agent in the installer (this is being worked on already for other reasons, right?) The kernel firmware loading code and udev/hotplug take care of the rest. If the infrastructure for this was not ready by freeze time, an exception would be warranted, though I don't see any reason why it wouldn't be ready. For a non-early-loading driver which has embedded firmware, it requires: (1) an easy facility for inserting an "extra debs" CD or floppy in the installer (already present) (2) an easy facility for inserting an "extra udebs" CD or floppy in the installer (already present, I believe) (3) a udeb for the driver matching the kernel used in the installer (tedious, but certainly feasible) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) If the infrastructure for this was not ready by freeze time, an exception would be warranted, but I also don't see any reason why it wouldn't be ready. Yes, you'd have to build a bunch of drivers out of tree in non-free until they were converted to userland-firmware-loading. You already know how to do this, folks. For any driver which needs to load before the CD drive is mounted, it would appear to require (a) provisions in the installer for loading extra udebs (from where?) before mounting the CD, which are almost certainly infeasible (b) or an entire non-free installer release This is the only genuinely impractical case, and an exception *should* be made for it in the interests of installing on as much hardware as possible. This message is public domain. Please feel free to copy it to whereever you think it needs to be read. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]