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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Linus Torvalds <torvalds@...>
Cc: <david@...>, Marcel Holtmann <marcel@...>, David Woodhouse <dwmw2@...>, <jeff@...>, <arjan@...>, <akpm@...>, <alan@...>, <linux-kernel@...>
Date: Tuesday, July 15, 2008 - 6:20 pm

On Tuesday 15 July 2008, you wrote:

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.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Prosaic firmware issues, Alexey Dobriyan, (Tue Jul 15, 9:11 pm)
Re: Prosaic firmware issues, Linus Torvalds, (Tue Jul 15, 9:45 pm)
Re: Prosaic firmware issues, David Woodhouse, (Wed Jul 16, 1:54 am)
Re: Prosaic firmware issues, Alexey Dobriyan, (Wed Jul 16, 10:19 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Frans Pop, (Tue Jul 15, 6:20 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Henrique de Moraes Holschuh..., (Tue Jul 15, 2:05 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Arjan van de Ven, (Tue Jul 15, 12:04 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Benjamin Herrenschmidt, (Tue Jul 15, 1:05 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Benjamin Herrenschmidt, (Tue Jul 15, 1:15 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Arjan van de Ven, (Tue Jul 15, 12:56 am)
Re: [GIT *] Allow request_firmware() to be satisfied , Oliver Neukum, (Tue Jul 15, 2:23 am)
Re: [GIT *] Allow request_firmware() to be satisfied , Oliver Neukum, (Tue Jul 15, 12:52 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Tue Jul 15, 4:45 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Wed Jul 16, 5:28 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Thu Jul 17, 4:42 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Thu Jul 17, 6:25 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Tue Jul 15, 7:45 pm)