From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933698AbbCRVuf (ORCPT ); Wed, 18 Mar 2015 17:50:35 -0400 Received: from mail-yh0-f43.google.com ([209.85.213.43]:34178 "EHLO mail-yh0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933669AbbCRVuc (ORCPT ); Wed, 18 Mar 2015 17:50:32 -0400 Date: Wed, 18 Mar 2015 17:50:28 -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: <20150318215028.GF25365@htj.duckdns.org> References: <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> <20150318210226.GE25365@htj.duckdns.org> <20150318214126.GJ11485@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318214126.GJ11485@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, Dmitry. On Wed, Mar 18, 2015 at 02:41:26PM -0700, Dmitry Torokhov wrote: > You are over-stating the boot order guarantees that storage provides. > Yes, you can scan devices and partitions simultaneously on the same > controller, but it will break if controllers are registered in different > order. And if you are delaying registering cone controller because > another that you consider "first" has not done probing, you are stalling > the boot process. It may be OK for "leaf" devices, which disks are > usually are, bit not when you delaying initialization of a device that > is in a middle of the device tree. Can't we make it "transitive"? Split ->probe() into two parts so that attaching the leaf devices run from the completion part of the split ->probe(). Sure, a lot of userlands we have nowadays can handle probe order changing but we stil have use cases where the order matters. Why introduce two separate behaviors when we can make the pararell ordering transitive? Doing things based on a big switch is going to create two largely separate modes of operations. For a lot of cases, the gain in boot time might not be enough to turn on the switch and we sure can't default to turning it on. This is a deviation we can avoid with reasonable amount of effort. The trade-off seems pretty clear to me. Thanks. -- tejun