lkml.org 
[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
From
Date
On Tue, 2008-07-15 at 12:27 -0700, Linus Torvalds wrote:
>
> On Tue, 15 Jul 2008, Marcel Holtmann wrote:
> >
> > using /lib/firmware/`uname -r`/ is actually not a bad idea. You only
> > have to fix udev to actually include this in the list of directories to
> > look for firmware files. Also Ubuntu is already doing this.
>
> I really don't think we need to even "fix udev".
>
> Why don't we just load it ourselves? Esepcially as there are probably
> places that try to avoid udev entirely, or at least use a very
> cut-down-version.
>
> We should be fairly trivially able to be _entirely_ backwards compatible
> with any sane setup (not the _sane_ part! It implies that people don't
> copy individual modules around by hand!), with no actual breakage or need
> for distros to even update anything at all - just make the kernel able to
> look up binary blobs in the same place it installed them.
>
> That sounds like the RightThing(tm) to do _regardless_ of any other
> issues, doesn't it? If the kernel installs it in some known place, why
> should it not just read them from that known place?

I'm unconvinced that the kernel should be setting this kind of policy.

But I suppose if you make it tunable in sysfs and just switch to calling
do_filp_open() directly from firmware_class.c instead of punting to
userspace, that might work.

It leaves you with less flexibility -- it would prevent stuff like the
udev trick I posted a week or so back to fix the Intel microcode loader
by automatically generating the needed binary blob on the fly from
microcode.dat, for example.

We also have a long tradition of pointing and laughing at people who
want to call open() from within the kernel. But it _could_ work,
certainly.

I'm not really convinced it helps though. The script which creates an
initrd still needs to look at the MODULE_FIRMWARE() tag and include the
right firmware file. If that's broken, you're screwed anyway. And that
was true in 2.6.25 too.

--
dwmw2



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