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

[Arjan van de Ven]

> > 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.

I'm not arguing that

>   That's why I say there's
> no chicken-and-egg:  presumption of such implies half a solution.

I think you haven't read what I wrote. The part that makes up the
chicken-and-egg problem is the part where there is no infrastructure to
USE such firmware in initrds, to distribute it with the kernel image
etc. 

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

and for the distro people who need to get their distro to do this sort
of thing very smoothly. It also, to put it bluntly, shuts the "fanatics"
up because they have their solution immediately, while others that may
need more time to get their distro ready, have such more time. I don't
have the illusion that any distro will do the infrastructure work if
there are no drivers that are going to use it. Nor do I have the
illusion that driver writers will make a hard switch until such
infrastructure is out there en masse.

Note that I don't even mention anything about not shipping the firmware
in the kernel tarbal. It might be an option in the end, depending on how
the infrastructure developers; but that is not part of the stalemate
that I see. You seem to be focused on only that thing, but to be honest,
for me that is the least interesting/controversial part.



-
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/