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

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

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux