Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757486AbXEQRNW (ORCPT ); Thu, 17 May 2007 13:13:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755983AbXEQRNM (ORCPT ); Thu, 17 May 2007 13:13:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]:38691 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755850AbXEQRNK (ORCPT ); Thu, 17 May 2007 13:13:10 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p6CZcH0IT7jBifaFOs22CjiVbREb0kHzlctnHFCKfJMbBuveIZRE9HW3IkaVbbsMnGkjiOJtNb7B5WS8mA6RGeP83UTULwKQltE4vXOXKhoJdRWhqydMPnKxy1j/M6p7vgkrLSY5ripk1QJIhor9zx5C8714SflYByX982mZVEc= Message-ID: Date: Thu, 17 May 2007 22:43:06 +0530 From: "Satyam Sharma" To: "Matthew Wilcox" Subject: Re: Asynchronous scsi scanning Cc: "Simon Arlott" , "James Bottomley" , "Dave Jones" , "Linux Kernel Mailing List" , linux-scsi@vger.kernel.org, kernel-packagers@vger.kernel.org, "Robert P. J. Day" In-Reply-To: <20070516025121.GK10562@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1179153096.3703.23.camel@mulgrave.il.steeleye.com> <17841.simon.1179228389@5ec7c279.invalid> <20070515120228.GI10562@parisc-linux.org> <4649E03A.1090004@simon.arlott.org.uk> <20070515172905.GJ10562@parisc-linux.org> <20070516025121.GK10562@parisc-linux.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2522 Lines: 70 Hi Matthew, On 5/16/07, Matthew Wilcox wrote: > [...] > > /sys/module/scsi_mod/parameters/wait_for_async_scans (?) > > Doesn't really matter, but perhaps who created the sysfs namespace > > for scsi in /sys/module/scsi_mod/... could be the best person to suggest. > > No, it does matter. Your suggestion doesn't work, because > /sys/module/scsi_mod/parameters/ belongs to the module code. To create > a new attribute there, you use the module_param() code -- and there's > no way to have code called when your parameter is changed. Ok, thanks for pointing out that /sys/module/scsi_mod/parameters/wait... is _wrong_. Could you suggest something that would be _right_? > > OK, I'll get really silly here myself. I don't want even that half a second > > of > > overhead when that module is being _built_ (during make modules), not > > the overhead of copying / installing at modules_install time. > > You're claiming that 0.7 second (I just timed it on a 3 year old > laptop) *inconveniences* you? ... On 5/16/07, Satyam Sharma wrote: OK, I'll get really silly here myself. ... ... On 5/16/07, Satyam Sharma wrote: It's not _inconvenient_. Just that writing/building a module for accomplishing something like that ... is just not _right_. ... On 5/16/07, Satyam Sharma wrote: static int __init wait_scan_init(void) { scsi_complete_async_scans(); return 0; /* BTW this could've been return scsi_complete_async_scans(); * I see scsi_complete_async_scans() never fails, but still. */ } late_initcall(wait_scan_init); ... does _not_ deserve to be a module, and writing/building a module for something like this (just to run a function in some kernel subsytem) does not seem to be the proper way to solve the problem either. ... > This whole thing is such a tempest in a teapot. I really don't > understand why you care so much. You're almost right here. But IMHO this is simply a case of doing something in some kernel subsystem in a proper/better way than it is being done presently. Anyway, like I said on another thread, discussions here tend to be most productive only over code, so I'll try and make a patch to do this some other way. Thanks, Satyam - 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/