Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752092AbaFFP0I (ORCPT ); Fri, 6 Jun 2014 11:26:08 -0400 Received: from mail-oa0-f46.google.com ([209.85.219.46]:33716 "EHLO mail-oa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbaFFP0G (ORCPT ); Fri, 6 Jun 2014 11:26:06 -0400 MIME-Version: 1.0 In-Reply-To: References: <1401896895-14262-1-git-send-email-tiwai@suse.de> Date: Fri, 6 Jun 2014 11:26:05 -0400 X-Google-Sender-Auth: FHWOBAsBvi6YCPIvphKXdcQK_yE Message-ID: Subject: Re: [PATCH v2] firmware loader: allow disabling of udev as firmware loader From: Ilia Mirkin To: Ming Lei Cc: Tom Gundersen , Takashi Iwai , 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 11:19 AM, Ming Lei wrote: > On Fri, Jun 6, 2014 at 10:15 PM, Tom Gundersen wrote: >> 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." > > 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. There are basically no reasonable conditions when it should be enabled, irrespective of udev version. Countless man-hours have been spent debugging issues with weird hangs caused by this. I know I've spent at least one of my own working out why resume from suspend hung mysteriously. Is there an actual, _real_, situation where the usermode helper is used for something constructive (on a kernel that can load its own firmware)? Certainly one can be imagined, but were there any systems that made use of that imagination? -ilia -- 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/