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 for Android: free password hash cracker in your pocket

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

Message-ID: <a781481a0705180614u72556b39pf4d0afd00c8c0ce5@mail.gmail.com>
Date:	Fri, 18 May 2007 18:44:26 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Matthew Wilcox" <matthew@....cx>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, kernel-packagers@...r.kernel.org
Subject: Re: Asynchronous scsi scanning

On 5/18/07, Matthew Wilcox <matthew@....cx> wrote:
> On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote:
> > [ BTW, this is the last time I'll try explaining this to you. ]
>
> Oh good.  Perhaps you can just drop the idea entirely and give up?

Well, I do plan to, at least as far as convincing you or getting some
alternative in mainline is concerned.

> > The one-line patch you're suggesting *would*not*allow* one to use the async
> > scanning _at_all_. If one really wants to use async scanning reliably (even
> > in
> > the future, as it can be turned on at boot-time later, like you very well
> > know),
> > that module *must* be built. Making it user-visible and/or optional would
> > *not*
> > be a solution but a *problem*. What I have been suggesting is *not* to make
> > this *dummy module* user-visible and/or optional but to _not_ use this
> > *dummy module* for this purpose in the first place.
>
> That's simply not true.  There are other ways of using async scanning
> reliably -- as Peter Jones pointed out.  If you're relying on the earlier
> semantics of "modprobe returned, therefore scanning is complete", then
> yes, it's unreliable.  But if you're using kevents/udev/etc to find out
> when devices have been discovered, then it's not unreliable.

But I do hope the mainline kernel does want to give (by default) the best
way/interface of doing this for users/distros, at least. From Peter's mail,
I gather that we can do better than what we are presently doing.

> > [ This time, I don't see the subject changing, nor a "change in the general
> > direction of the thread blah blah blah", and still you feel compelled to not
> > maintain the CC list. Wow. ]
>
> I see trimming the CC list as a courtesy to those who've had enough of
> this pointless thread landing in their mailboxes.

Well you trimmed out those original "three users" who did show interest in
this in the first place. Anyway, pointless it indeed has become...
-
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/