From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752839AbaIIXCD (ORCPT ); Tue, 9 Sep 2014 19:02:03 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:61748 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbaIIXCA (ORCPT ); Tue, 9 Sep 2014 19:02:00 -0400 From: Dmitry Torokhov To: James Bottomley Cc: Tejun Heo , "Luis R. Rodriguez" , Lennart Poettering , Kay Sievers , Greg Kroah-Hartman , Wu Zhangjin , Takashi Iwai , Arjan van de Ven , "linux-kernel@vger.kernel.org" , Oleg Nesterov , hare@suse.com, Andrew Morton , Tetsuo Handa , Joseph Salisbury , Benjamin Poirier , Santosh Rastapur , One Thousand Gnomes , Tim Gardner , Pierre Fersing , Nagalakshmi Nandigama , Praveen Krishnamoorthy , Sreekanth Reddy , Abhijit Mahajan , Cas ey Leedom , Hariprasad S , MPT-FusionLinux.pdl@avagotech.com, Linux SCSI List , "netdev@vger.kernel.org" Subject: Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM Date: Tue, 09 Sep 2014 16:01:32 -0700 Message-ID: <5762134.BLS0EbmNJd@dtor-glaptop> User-Agent: KMail/4.13.3 (Linux/3.13.0-34-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1410302783.13298.50.camel@jarvis.lan> References: <20140905174925.GA12991@mtj.dyndns.org> <20140909224143.GB3154@mtj.dyndns.org> <1410302783.13298.50.camel@jarvis.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote: > On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote: > > > > The thing is that we have to have dynamic mechanism to listen for > > device attachments no matter what and such mechanism has been in place > > for a long time at this point. The synchronous wait simply doesn't > > serve any purpose anymore and kinda gets in the way in that it makes > > it a possibly extremely slow process to tell whether loading of a > > module succeeded or not because the wait for the initial round of > > probe is piggybacked. > > OK, so we just fire and forget in userland ... why bother inventing an > elaborate new infrastructure in the kernel to do exactly what > > modprobe & > > would do? Just so we do not forget: we also want the no-modules case to also be able to probe asynchronously so that a slow device does not stall kernel booting. Thanks. -- Dmitry