Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel,use it in more drivers.

From: Linus Torvalds
Date: Tue Jul 15 2008 - 19:44:32 EST




On Tue, 15 Jul 2008, david@xxxxxxx wrote:
>
> becouse the tools that wrote the initrd already put the modules in. I don't
> maintain those tools, they came with the distro. we're just asking to not
> require those tools to be updated immediatly.

But mkinitrd (which is the _only_ thing that people tend to use to write
initrd's - is there even anything else) has already been doing this for
years, as has been pointed out several times.

This is why I harped on the fact that you already rebuilt your initrd
image.

So this really isn't a "updated immediately" issue, afaik. Googling for

mkinitrd MODULE_FIRMWARE

shows a patch from two years ago as the #1 hit in order to make the
aic94xx driver work.

Loking down a bit, there's a hotplug discussion from early 2005 (gmane
says "3 years, 20 weeks, 3 days, 6 hours and 39 minutes ago" in the
header).

Quite frankly, if it's still a problem, there's simply something _wrong_
with the distribution. And yeah, maybe people need to update their kernel
building tools.

I already pointed out how the kernel development team quite often says "we
will no longer build with gcc-.xyz because it's too old and buggy". The
build tools requirements are simply *different* from the runtime tools.

If it's literally just an issue of an mkinitrd that is too damn old, why
don't we just make that test at kernel build time. *EXACTLY* the same way
we test for compilers that are too old, and refuse to build with them?

(And no, I have no idea which version we should test for. In fact,
mkinitrd seems to be singularly hard to test versions for, in that it
seems to want the user to be root even just to give the version output.
Ooh).

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