From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756576AbbCRVCd (ORCPT ); Wed, 18 Mar 2015 17:02:33 -0400 Received: from mail-vc0-f173.google.com ([209.85.220.173]:39315 "EHLO mail-vc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755564AbbCRVCa (ORCPT ); Wed, 18 Mar 2015 17:02:30 -0400 Date: Wed, 18 Mar 2015 17:02:26 -0400 From: Tejun Heo To: Dmitry Torokhov Cc: Greg Kroah-Hartman , "Luis R . Rodriguez" , linux-kernel@vger.kernel.org, Arjan van de Ven , Rusty Russell , Olof Johansson , Tetsuo Handa Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe Message-ID: <20150318210226.GE25365@htj.duckdns.org> References: <20150318165618.GB21564@htj.duckdns.org> <20150318174544.GD11485@dtor-ws> <20150318181652.GA25365@htj.duckdns.org> <20150318182318.GF11485@dtor-ws> <20150318182742.GB25365@htj.duckdns.org> <20150318183731.GG11485@dtor-ws> <20150318184550.GC25365@htj.duckdns.org> <20150318193622.GH11485@dtor-ws> <20150318195141.GD25365@htj.duckdns.org> <20150318202605.GI11485@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318202605.GI11485@dtor-ws> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Mar 18, 2015 at 01:26:05PM -0700, Dmitry Torokhov wrote: > Tejun, I lost you here. Certainly you are not arguing for going through > the drivers one by one and making their module init code to engage > async_schedule to continue the device creation in link order (well, > sorta, since deferred probing already violates it). Kind of, yes, but not by driver-by-driver, but by subsystem. I don't think we have too many subsystems where probing order matters and the ordering only matters within each subsystem. > Also, it is not only kernel that may not be prepared for asynchronous > probing, but userspace as well. And I do not think that we should be > working towards preserving the init order in the long run as more and > more bits become hot pluggable and we should be able to handle devices > come and go gracefully anyway. It's not about supporting or not supporting hotplugging. Most of the storage devices support hotplugging but still maintain boot order and at least for storage devices there are pretty good reasons for doing so especially as we can do so w/o giving up on parallel probing. The problem is that if you hinge enabling of general async probing on virtually all userlands being okay with storage devices (or ttyS devices and so on), we won't be able to enable this, ever. This is a solvable problem. Making e.g. SCSI host probing transitive in terms of probe ordering shouldn't be too difficult. We can't add a generic async probing mechanism at the driver layer ignoring this aspect. Thanks. -- tejun