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

[Ming Lei]

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.


Thanks,
--
Ming Lei
--
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/