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/