lkml.org 
[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
Linus Torvalds wrote:
>
> On Mon, 14 Jul 2008, Jeff Garzik wrote:
>> Do you really think embedded system and micro distro authors are in 100%
>> agreement that /lib/firmware is best for their situation? Really?
>
> Umm. Why are you bringing up these total red herrings?
>
> Those embedded systems can just build everything into one image, and are
> much better off using no modules at all.

Oh come on, embedded systems use modules all the time, and surely you
know that. My router running OpenWRT says

root@gw:~# ipkg list | grep -c kmod
91

Therefore, simple kernel replacement can create a regression by doing

1) build 2.6.26 kernel, including all associated kernel module packages
("kmod-*")
2) install new kernel and associated kmod packages
3) watch system work as expected
4) build 2.6.27 kernel, including all associated kernel module packages
5) install new kernel and associated kmod packages
6) watch system fail

Why fail? The package file lists for kmod-* ipkg's are unaware of any
firmware needs newly added in 2.6.27.

So the driver gets packaged, but ipkg build process is completely
unaware of the additional firmware requirement until a manifest is
updated. The normal build process appears to succeed -- yet at next
boot you see that it failed.

Similar breakage for driver disks.

Similar breakage for older versions of mainstream distros (won't get
copied into initrd, with obvious results).


> But how about instead of complaining, help add the infrastructure then, so
> that you can insert those firmware things into modules and still use just
> one single interface?
>
> Move _forward_, not backwards.

Does that mean you agree it's a regression? :) Sure, I'd be happy to
help fix the damage.

I am still surprised this was merged at all in its state, and am a bit
disappointed. This one

* removed choice, by removing ability to build firmware into modules

* forced a flag day build process change upon all distros/builders who
switch to >= 2.6.27. no build script updates == non-working drivers.

* the legal subtext of these changes was not mentioned at all

Generally, we don't do that. Generally, we give distros the ability to
choose between old-way and new-way during a time of transition.
Generally we make it easy for newer kernels to work on existing systems,
maximizing the [test] audience.

Jeff





\
 
 \ /
  Last update: 2008-07-15 09:25    [W:0.166 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site