From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162AbbCRU0O (ORCPT ); Wed, 18 Mar 2015 16:26:14 -0400 Received: from mail-ie0-f178.google.com ([209.85.223.178]:36067 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754737AbbCRU0L (ORCPT ); Wed, 18 Mar 2015 16:26:11 -0400 Date: Wed, 18 Mar 2015 13:26:05 -0700 From: Dmitry Torokhov To: Tejun Heo 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: <20150318202605.GI11485@dtor-ws> References: <1421451197-19723-7-git-send-email-dmitry.torokhov@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318195141.GD25365@htj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2015 at 03:51:41PM -0400, Tejun Heo wrote: > Hello, > > On Wed, Mar 18, 2015 at 12:36:22PM -0700, Dmitry Torokhov wrote: > > Because they are not inherently problematic. I mean from the kernel POV > > they work fine, the question is if your userspace can deal with them or > > not. For example ChromeOS userspace is fine. > > async already provides mechanisms to solve the above problem. This > doesn't have to be an either-or thing. I still don't get why we > aren't converting drivers properly over to async so that they still > follow the ordering rules where necessary. What's wrong with just > blacklisting the ones which can't follow ordering rules for now and > lifting the blacklist as they get fixed? That'd provide a gradual > transition path with the matching incentive for converting the drivers > while not disturbing userland. 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). 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. Thanks. -- Dmitry