lkml.org 
[lkml]   [2007]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2007-05-18 05:45    [W:4.176 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site