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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
