Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757248Ab2HYTAX (ORCPT ); Sat, 25 Aug 2012 15:00:23 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:37106 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757041Ab2HYTAV (ORCPT ); Sat, 25 Aug 2012 15:00:21 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Sat, 25 Aug 2012 11:59:59 -0700 X-Google-Sender-Auth: L5S2tN_gLjuzXfIsm5tXuLBkjVo Message-ID: Subject: Re: udev 182: response timeout for request_firmware in module_probe path To: Kay Sievers Cc: Ming Lei , Linux Kernel Mailing List , Greg Kroah-Hartman , Johannes Berg , Larry Finger , systemd-devel@lists.freedesktop.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1198 Lines: 28 On Thu, Aug 23, 2012 at 8:31 AM, Kay Sievers wrote: > > Calling out from inside the kernel and blocking in a firmware loading > userspace transaction during module_init() is kind of weird. It's *very* common. I personally would prefer if drivers did their firmware loading not at probe time, but at device open time, but that's not always necessarily possible. More importantly, it's not actually how things are done. So udev had better be fixed. The whole "no regressions" should be the rule not just for the kernel, but it damn well should be the rule at *least* also for projects like udev that are so closely related to the kernel. The "I wish things were otherwise than they are" mindset is wishful thinking. Reality is that probing - and firmware loading - happens from the module init routines quite often, and it clearly used to work. So udev broke. Fix it, don't argue that you wish things were otherwise. Linus -- 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/