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

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

Friendly,

Sven Luther



Reply to: