[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+5PVA5J0OhmSsy3zOi=z8Ck7QJHVXng=q7OZNOu4nzi6qNA-A@mail.gmail.com>
Date: Thu, 4 Oct 2012 09:39:41 -0400
From: Josh Boyer <jwboyer@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Walls <awalls@...metrocast.net>,
Greg KH <gregkh@...uxfoundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Ming Lei <ming.lei@...onical.com>, Kay Sievers <kay@...y.org>,
Lennart Poettering <lennart@...ttering.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kay Sievers <kay@...hat.com>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Michael Krufky <mkrufky@...uxtv.org>,
Ivan Kalvachev <ikalvachev@...il.com>
Subject: Re: udev breakages - was: Re: Need of an ".async_probe()" type of
callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls <awalls@...metrocast.net> wrote:
>>
>> I don't know if you can remove the /sys/.../firmware ABI altogether, because there is at least one, somewhat popular udev replacement that also uses it: mdev
>>
>> http://git.busybox.net/busybox/plain/docs/mdev.txt
>
> Heh. That web doc documents /lib/firmware as being the place to be.
>
> That said, there's clearly enough variation here that I think that for
> now I won't take the step to disable the udev part. I'll do the patch
> to support "direct filesystem firmware loading" using the udev default
> paths, and that hopefully fixes the particular case people see with
> media modules.
As you probably noticed, we had a tester in the RH bug report success
with the commit you included yesterday.
Do you think this is something worth including in the stable kernels
after it gets some further testing during the merge window? Perhaps
not that specific commit as there seems to be some additional changes
needed for configurable paths, etc, but a backport of the fleshed out
changeset might be wanted.
We have a new enough udev in Fedora 17 to hit this issue with 3.5 and
3.6 when we rebase. I'm sure other distributions will be in similar
circumstances soon if they aren't already. Udev isn't going to be
fixed, so having something working in these cases would be great.
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists