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

[Tom Gundersen]

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."

?

Cheers,

Tom
--
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/