Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752060AbaFFOPZ (ORCPT ); Fri, 6 Jun 2014 10:15:25 -0400 Received: from mail-qa0-f51.google.com ([209.85.216.51]:40411 "EHLO mail-qa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751640AbaFFOPY (ORCPT ); Fri, 6 Jun 2014 10:15:24 -0400 MIME-Version: 1.0 X-Originating-IP: [84.49.246.117] In-Reply-To: References: <1401896895-14262-1-git-send-email-tiwai@suse.de> From: Tom Gundersen Date: Fri, 6 Jun 2014 16:15:03 +0200 Message-ID: Subject: Re: [PATCH v2] firmware loader: allow disabling of udev as firmware loader To: Takashi Iwai Cc: Ming Lei , LKML , Greg KH , Stefan Roese , Arnd Bergmann , Abhay Salunke , Kay Sievers Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 6, 2014 at 4:03 PM, Takashi Iwai wrote: > At Fri, 6 Jun 2014 07:00:22 +0800, > Ming Lei wrote: >> >> On Thu, Jun 5, 2014 at 11:15 PM, Tom Gundersen wrote: >> > On Thu, Jun 5, 2014 at 4:54 PM, Ming Lei 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/