Re: kernel firmwares: GR proposal
Frederik Schueler wrote:
So, this is an "I'm OK with the actual GR but object strongly to the
overview" post.
> 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
"For a few device drivers...."
> 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
"It is usually, but not always, very easy 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
"(if they are not moved to non-free)"
> cripple the kernel to an extent where it becomes unusable for most of
"for some 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.
OK, this was full of inaccuracies noted above. I have to strongly oppose
this characterization of the issues.
> 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,
"because we are not willing to try to fix it and we have not given anyone
else sufficient information to"
Sorry to be so annoyed. I can't even find 'anna', which is supposedly the
module which needs to be fixed. Where do I download it from? I have asked
debian-boot on previous occasions.
> 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.
Like a month or two, maybe. If people actually bother to work on it, or to
accept other people's work on it.
> 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.
OK, this is good. :-) Does this mean that the patches converting the tg3
driver to use firmware loading will be reaccepted?
> So, we propose this GR:
>
> 1. We affirm that our Priorities are our users and the free software
> community (Social Contract #4);
Technically this is wrong. The priorities are "our users and free
software". Not "the free software community". Please fix this; it means
something different.
> 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.
This ("without further conditions") would seem to promise that firmware will
be included even if it doesn't actually carry a license which permits
redistribution (as is the case for over 50 BLOBs in the upstream Linux
kernel). Is this correct? Are you specifically ordering the ftpmasters to
carry material which is technically improperly licensed?
If so, that's OK by me (it doesn't give me any legal liability), and it has
the substantial benefit of actually addressing the status of the majority of
upstream BLOBs in etch. But it should be *very clear* that this is what is
happening: that this GR is making a *legal liability* decision for Debian.
Note that I am not comfortable personally working on the drivers
containing improperly licensed firmware. (Except for working on getting a
proper license, that is.) You may well find that the other volunteers for
converting drivers to firmware loading are not comfortable working on them
either. This is bound to be a problem, given that the number of BLOBs with
good, clear licenses is quite small.
> 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).
This is actually a reasonable GR which I could support, except for the
misleading prologue.
> on behalf of the kernel- and release team
> Frederik Schueler
>
--
Nathanael Nerode <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: