linux-kernel - Re: Asynchronous scsi scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0705172041q6bc87f04v7a60eb62ad26d6@mail.gmail.com>
Date:	Fri, 18 May 2007 09:11:58 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Benjamin LaHaise" <bcrl@...ck.org>
Cc:	"Matthew Wilcox" <matthew@....cx>,
	"Christoph Hellwig" <hch@...radead.org>,
	"Simon Arlott" <simon@...e.lp0.eu>,
	"James Bottomley" <james.bottomley@...eleye.com>,
	"Dave Jones" <davej@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, kernel-packagers@...r.kernel.org,
	"Robert P. J. Day" <rpjday@...dspring.com>
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@...ck.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/