Re: non-free firmware
sven.luther@wanadoo.fr 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|
Reply to: