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

Frans Pop
2008-07-15T22:21:00Z

On Tuesday 15 July 2008, you wrote:
> Why is it suddenly so important that a kernel be 'zero impact' for that
> module case, when it's never been zero impact for that case before? You
> had to rewrite the initrd to begin with, but now you're not willing to
> do it again, just because you have to rewrite it slightly
> _differently_?

Because in most cases users do not write and maintain the scripts used to
build custom kernels themselves. They use (huge and way too) tools like
Debian's 'make-kpkg' for that.

Because users may want to build a custom 2.6.27 in for example a Debian
Etch environment using the make-kpkg package that is available in that
release of Debian. Or even a Debian Lenny environment (Lenny is about to
be frozen so is very unlikely to include whatever may be needed for
this).

Why is it good to extend the lifetime of the i386 and amd64 symlinks for
x86 images by an extra few years so that older versions of kernel
packaging tools - like make-kpkg - don't break, but is breaking the exact
same tools with this firmware change suddenly OK?

Users _want_ to be able to build new kernels in older environments. Why
take that option away from them? Why force them through the pain of
partial upgrades of their userspace if it can so easily be avoided?

>From my PoV adding this option is a no-brainer: if Jeff is willing to do
the work, then what harm can it do? The benefits to me are obvious.
I really don't get what you have against it.

Cheers,
FJP

P.S. Sorry to keep coming up with Debian examples, but that's the
environment I know.