Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

From: Jeff Garzik
Date: Tue Apr 05 2005 - 14:59:13 EST


On Tue, Apr 05, 2005 at 09:40:24PM +0200, Arjan van de Ven wrote:
>
> > * The firmware distribution infrastructure is basically non-existent.
> > There is no standard way to make sure that a firmware separated from the
> > driver gets to all users.
> >
> > * The firmware bundling infrastructure is basically non-existent.
> > (Arjan talked about this) There needs to be a a way to ensure that the
> > needed firmwares are automatically added to initramfs/initrd.
> >
> > * There is no chicken-and-egg problem as Arjan mentions.
>
> actually there is; you just perfectly described it. Until we have
> drivers that can use such firmware (and need it in initrds and the like)
> infrastructure for that is unlikely to come into existence, and until
> there is such infrastructure, driver authors like you are unlikely to
> want to transition to loading firmware. Now there is also your other
> point about the request_firmware() interface being too primitive, and
> that sure sounds valid. So to move forward two things need to happen
>
> 1) the infrastructure needs expanding to be useful for more drivers
>
> 2) the chicken and egg stalemate needs breaking. One way to do that is
> to have dual-mode drivers for a while (eg drivers that request_firmware
> () and if that fails, use the built-in firmware) so that the other
> outside-the-kernel infrastructure can be developed and deployed.

The tg3 firmware should be delivered with the kernel; and any
infrastructure that does not continue to work seamlessly with
firmware-separate-from-tg3 is a non-starter. That's why I say there's
no chicken-and-egg: presumption of such implies half a solution.

Dual mode drivers are only useful for the 1-2 developers working on
firmware loading.

Someone needs to make the effort to create and test a solution, rather
than half measures which -do- imply a c-and-e problem.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/