[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel firmwares: GR proposal

On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:


> 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).

...and get Lars tatooed! :)



GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply to: