Re: kernel firmwares: GR proposal
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> 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...."
What about the more neutral "for some devices" ?
> > 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..."
Err, please, tell us how we can make this distinction ?
> > 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)"
Until we have the non-free support in d-i, this is a moot point. And the d-i
team leadership has clearly stated it will not happen for etch.
> > cripple the kernel to an extent where it becomes unusable for most of
> "for some of...."
Well, the idea here is that the problematic devices are in widespread use, and
thus the portion of users affected are significant. So, maybe somethign a bit
more strong than some, while being a bit less strong than most would be better ?
> > 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.
Full of inacuracies is maybe a wee bit overstated, don't you think ? I would
say this statement is as full of inacuracies as the original text :)