Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752041AbaFFODN (ORCPT ); Fri, 6 Jun 2014 10:03:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54274 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751694AbaFFODK (ORCPT ); Fri, 6 Jun 2014 10:03:10 -0400 Date: Fri, 06 Jun 2014 16:03:07 +0200 Message-ID: From: Takashi Iwai To: Ming Lei Cc: Tom Gundersen , LKML , Greg KH , Stefan Roese , Arnd Bergmann , Abhay Salunke , Kay Sievers Subject: Re: [PATCH v2] firmware loader: allow disabling of udev as firmware loader In-Reply-To: References: <1401896895-14262-1-git-send-email-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Takashi -- 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/