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

[Takashi Iwai]

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.


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