Messages in this thread | | | Date | Fri, 18 May 2007 09:11:58 +0530 | From | "Satyam Sharma" <> | Subject | Re: Asynchronous scsi scanning |
| |
> On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote: > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote: > > > Hmmm, actually those other users could easily write and maintain > > > a 20-line patch that does the wait for async scans thing for them > > > using /proc/scsi/scsi in any case. > > > > How about the three users who're bothered by this extra module being > > built maintain a one-line patch to Kconfig and leave well enough alone?
So you expect users bothered with this to actually get on lkml / write to it and complain about this? And because not everybody else who is disgusted with this user-invisible-default-m-module-way-of-solving-this-problem (when it shouldn't be a module at all) is doing that, it's just "the three"?
It is *shocking* / funny how you *still* want to defend that:
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);
deserves/must be a separate module, and that doing:
config SCSI_WAIT_SCAN tristate default m
is the best way to solve this !!!
In any case, firstly, I'm not a user of SCSI at all. I'm still interested in this, but because for me (like I've said twice already) this is simply a (trivial, perhaps) matter of doing something in the kernel in a better/proper way, than what is being done currently.
It's also somewhat a matter of *taste* (and hence subjective), if you _still_ don't get it, Matthew, then there's no point continuing this thread and trying to convince you ad infinitum.
On 5/18/07, Benjamin LaHaise <bcrl@kvack.org> wrote: > The module has an added bonus that it doesn't require any new tools to > make work. Doing it via sysfs/procfs means a new rev of whatever tool > generates the boot initrd, plus fixing up boot scripts. Loading a module > can be done via a simple option to the existing boot tools.
I do not expect the alternative ways to change this that we've discussed so far to necessitate any major "fixing up", but yeah a minor touch-up would clearly be required. - 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/
| |