Re: [PATCH v2] firmware loader: allow disabling of udev as firmware loader

[Ilia Mirkin]

On Fri, Jun 6, 2014 at 11:19 AM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
> On Fri, Jun 6, 2014 at 10:15 PM, Tom Gundersen <teg@xxxxxxx> wrote:
>> On Fri, Jun 6, 2014 at 4:03 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
>>> At Fri, 6 Jun 2014 07:00:22 +0800,
>>> Ming Lei wrote:
>>>>
>>>> On Thu, Jun 5, 2014 at 11:15 PM, Tom Gundersen <teg@xxxxxxx> wrote:
>>>> > On Thu, Jun 5, 2014 at 4:54 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
>>>> >>> Ubuntu currently enables the firmware loader in both the kernel and in
>>>> >>> udev, so would not yet have a problem here at the moment. However, I
>>>> >>> spoke with Martin Pitt and he told me that both Debian and Ubuntu
>>>> >>> would like to switch this off in udev once it is possible (i.e., once
>>>> >>> this patch has been merged I guess). Fedora already did, and speaking
>>>> >>> for Arch we definitely would like to do the same. I did not check with
>>>> >>> other distros, but I'm pretty sure "everyone" will disable this in
>>>> >>> udev by the next cycle. At which point having it enabled in the kernel
>>>> >>> will cause real problems and bug reports.
>>>> >>
>>>> >> That won't cover the case of old distributions with new kernel,
>>>> >
>>>> > Again: disabling this option will not give problems (unless you have a
>>>> > custom setup), even on old userspace, only keeping it enabled on
>>>> > future userspace may.
>>>> >
>>>> >> do
>>>> >> you want to break/confuse these users?
>>>> >
>>>> > Not really, no :)
>>>> >
>>>> >>> For distro kernels that's not a problem, as they know what to do, but
>>>> >>> I guess for random kernel users we should give them the correct
>>>> >>> recommendation.
>>>> >>
>>>> >> Also I remember that android users put firmware under their
>>>> >> special path.
>>>> >
>>>> > That may be, but I don't think this text is primarily aimed at the
>>>> > people who put together Android systems... Surely their non-standard
>>>> > userspace means that a lot of the advice (and it is nothing else than
>>>> > advice!) in the help text does not necessarily apply?
>>>> >
>>>> >>>>>> It only falls back if the request fw is _not_ found from direct loading,
>>>> >>>>>> so it is reasonable to try to continue to look for it from user space.
>>>> >>>>
>>>> >>>>> Some drivers fall back to different firmware (e.g. different revision
>>>> >>>>> suffix) if the requested file isn't found.  So, this happens in
>>>> >>>>> reality.
>>>> >>>>
>>>> >>>> So do you think the fallback is better or worse? For CPU microcode
>>>> >>>> case, maybe it is fine, but for other devices, maybe it is better to
>>>> >>>> get a firmware for working at least.
>>>> >>>
>>>> >>> What usecase do you have in mind here? For people using stock udev,
>>>> >>> enabling the fallback will not give any benefit, but it will soon
>>>> >>
>>>> >> Again, we have old distributions, also it should make sense to fall back
>>>> >> to userspace for non-exist firmwares under default path.
>>>> >
>>>> > Even on old distributions, falling back to stock udev will not give
>>>> > any benefits. It will look in the same paths as the kernel and fail in
>>>> > the same way.
>>>> >
>>>> >>> start giving real problems...
>>>> >>
>>>> >> If there isn't firmwares at default path for devices, the device may
>>>> >> not work, and that is the real problem.
>>>> >
>>>> > These devices will never have worked with stock udev, as it looks in
>>>> > the same path as the kernel (the paths the kernel looks in was taken
>>>> > from udev to make sure they work the sam). So this must be a
>>>> > special/custom setup by someone who knows what they are doing, and
>>>> > hopefully knows how to answer the Kconfig.
>>>>
>>>> I have to say all your statement about old distributions is just your
>>>> take for granted, and you can't verified on all old distributions at all.
>>>> That is said, disabling fallback may cause regression on these
>>>> distributions.
>>>>
>>>> Given that the user helper(fallback) has been used for tens of
>>>> years on these distributions, I suggest you to change Kconfig
>>>> help message as something like below:
>>>>
>>>> If your aren't sure, please check your udev/systemd version, if it
>>>> is below than XXX or no udev/systemd shipped in your system,
>>>> say Y here, otherwise say N.
>>>
>>> Yeah, a detailed suggestion like the above would be more helpful.
>>
>> How about:
>>
>> "If you rely on a customized udev (or other userspace tool) to load
>> firmware from a non-standard path, say Y. Otherwise, say N. If your
>> udev version does not support firmware loading (which is currently the
>> upstream default), you must say N."
>
> Please make it explicit since we know the fisrt version of
> udev which disables firmware loading at default. And 'upstream
> default' isn't needed because it depends on udev upstream version, and
> 'currently' is confused too because old distribution ships old udev.
>
> Something like below should be enough:
>
> If you aren't sure, please check the udev/systemd version, if it
> is below than XXX or no udev/systemd shipped in your system,
> say Y here, otherwise say N.

There are basically no reasonable conditions when it should be
enabled, irrespective of udev version. Countless man-hours have been
spent debugging issues with weird hangs caused by this. I know I've
spent at least one of my own working out why resume from suspend hung
mysteriously. Is there an actual, _real_, situation where the usermode
helper is used for something constructive (on a kernel that can load
its own firmware)? Certainly one can be imagined, but were there any
systems that made use of that imagination?

  -ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/