Re: kernel firmwares: GR proposal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I second the below GR proposal.
Friendly,
Sven Luther
|| Overview:
||
|| The Linux kernel source contains device drivers that ship with firmware
|| files provided by the hardware manufacturer. They are uploaded during
|| the driver initialization to the corresponding hardware device.
||
|| Some of these binary image files are provided as a hexdump of register
|| bank settings, others consist in fact of compiled binary code which is
|| executed on the hardware device.
||
|| Any device driver in the Linux kernel is freely available in source
|| format and licensed under the GPL2. For many device drivers with
|| attached firmware, the firmware image is freely distributable along
|| with the corresponding driver. The most common source format for
|| firmwares is the hexdump char array. It is almost impossible to
|| distinguish between register dumps and binary code without asking the
|| device manufacturer who provided the firmware.
||
|| Removing every firmware which is distributed as hexdump only will
|| cripple the kernel to an extent where it becomes unusable for most of
|| our users, because popular network and scsi devices are among the
|| drivers in question. Without these drivers, the user's system might not
|| be installable at all.
||
||
|| The current situation:
||
|| We achieved a lot of progress compared with the situation in 2.6.8 (the
|| kernel that shipped with sarge). We were able to convince upstream that
|| a firmware loader is a good thing, and that firmware and kernel code
|| should be separated. This firmware loader was added in 2.6.13, and
|| meanwhile, more than 40 drivers have been converted to the new
|| infrastructure. However, this is not yet finished, and some important
|| drivers still use the old method. There will be a day where we can drop
|| the remaining legacy, but we are not there yet.
||
|| Also, though the firmware loader allows us to put the firmware where it
|| belongs to (main or non-free, depending on the case), the installer can
|| as of now only take udebs from main. Fixing this is not too hard, but
|| it is doubtful whether we can fix this in time for etch, and we do not
|| want to depend on that (and even then, we still would have non-free
|| firmware, see above). But since there is lots of hardware which needs
|| firmware for correct operation, the installer would not work for
|| mainstream hardware otherwise.
||
|| There are two ways how to deal with it:
|| 1. Accept these issues as transitional issues for now; or
|| 2. Delay etch for some serious time.
||
||
|| In our social contract, we promised that the users and the free software
|| community are our priorities. We firmly believe that our users profit
|| very much from releasing etch in time, and that this is important enough
|| that we can accept the transitional status with having a few firmware
|| images left in main that should belong somewhere else. Of course,
|| everyone who wants to make the number of such firmware images as small
|| as possible is welcome to help converting old firmware loaders to the
|| new standard, and working on the Debian installer. We are happy if this
|| issues become smaller or even vanishes, but we do not want this to be a
|| release blocker.
||
||
|| So, we propose this GR:
||
|| 1. We affirm that our Priorities are our users and the free software
|| community (Social Contract #4);
|| 2. We acknowledge that there is a lot of progress in the kernel firmware
|| issue; however, it is not yet finally sorted out;
|| 3. We give priority to the timely release of Etch over sorting every bit
|| out; for this reason, we will deliver firmware in udebs as long as it is
|| necessary for installation (like all udebs), and firmware included in
|| the kernel itself as part of Debian Etch, without further conditions.
||
||
|| We want to emphasize that the success of this GR is considered as
|| necessary by the kernel and release team for successfully delivering etch
|| in time (and to allow us a successful planning of that).
||
||
|| on behalf of the kernel- and release team
|| Frederik Schueler
||
|| --
|| ENOSIG
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE9gVk2WTeT3CRQaQRAkBiAJwMWRklUc4bX6wQJ/o0FFO6ipRRCwCeMgjT
AjCrkNmQtTGU/L4ih2SeWEI=
=gAca
-----END PGP SIGNATURE-----
Reply to: