From: Bill Nottingham <notting@redhat.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] Add a 'wait-scan' command to /proc/scsi/scsi.
Date: Wed, 25 Mar 2009 15:47:56 -0400 [thread overview]
Message-ID: <20090325194756.GA26465@nostromo.devel.redhat.com> (raw)
In-Reply-To: <20090325192653.GS14127@parisc-linux.org>
Matthew Wilcox (matthew@wil.cx) said:
> On Wed, Mar 25, 2009 at 03:03:21PM -0400, Bill Nottingham wrote:
> > Then where is a better place to put this, as scsi_wait_scan.ko is
> > a ridiculous interface for userspace?
>
> It would be nice if people would comment on "ridiculous interface"s when
> they're asked for feedback, instead of waiting more than two years.
Sure, but asking all people who might eventually have to use it
to always watch any possible interface addition isn't practical.
I would have hoped that the fact that the interface required loading
a module and immediately removing it by hand is suboptimal enough
that it wouldn't have gotten in in the first place.
> I think you're misunderstanding how to use scsi_wait_scan. The idea was
> that the bit of userspace that probes all the device drivers would do:
>
> modprobe fusion.ko
> modprobe aic79xx.ko
> modprobe sym53c8xx.ko
> modprobe scsi_wait_scan
> rmmod scsi_wait_scan
>
> et voila, you're done. It seems like you want random other bits of
> userspace to wait for scsi scanning to be done, and that wasn't the
> original intent.
Well, in the case I'm looking at, udev is what's loading the host
controllers, and there needs to be some sort of synchronization point
between that and LVM invocations, fsck, mount, etc. Since scans
aren't sent over as events for udev to catch, 'udevadm settle'
isn't enough. Removing, loading, and removing scsi_wait_scan works
here, but it just seems like a kludge.
I can trigger a load of scsi_wait_scan when hosts are registered
in udev, but that's still ugly, and sort of overkill.
Bill
next prev parent reply other threads:[~2009-03-25 19:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 19:00 Bill Nottingham
2009-03-25 19:00 ` [PATCH] Declare PIO_CMAP/GIO_CMAP as compatbile ioctls Bill Nottingham
2009-03-25 19:02 ` Bill Nottingham
2009-03-25 19:01 ` [PATCH] Add a 'wait-scan' command to /proc/scsi/scsi Christoph Hellwig
2009-03-25 19:03 ` Bill Nottingham
2009-03-25 19:26 ` Matthew Wilcox
2009-03-25 19:47 ` Bill Nottingham [this message]
2009-03-25 20:36 ` Matthew Wilcox
2009-03-26 14:47 ` Bill Nottingham
2009-03-26 17:25 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090325194756.GA26465@nostromo.devel.redhat.com \
--to=notting@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®