On Sat, 2006-06-10 at 17:38 +0100, Christoph Hellwig wrote:
> On Sat, Jun 10, 2006 at 12:34:46PM -0400, Ben Collins wrote:
> > 1394 bus rescanning takes a _lot_ longer than a PCI rescan. If we don't
> > do this in a kthread, then we have to do it as a tasklet, and take a
> > chance of stalling for a few seconds (not ms), preventing other
> > tasklet's from running. Suboptimal, IMO.
>
> This is just user-initiated FC rescans. And I doubt they take as long
> as parallel scsi rescans which can go into the minutes range easily.
> Nothing will be stalled by calling this except the caller, which would
> usually be echo called from some shell, something the user can put in
> the background using job control.
Most rescans are initiated by a bus reset (usually caused by a
connect/disconnect of a device) that is detected in interrupt.
Obviously, we cannot initiate these rescans in interrupt, so a tasklet
or kthread is the only option.
The reason for handling user-initiated rescans (through some sysfs
interface?) and hardware-initiated rescans in the same place is code
simplicity, and synchronization.
I'm not sure what your implying about user-initiated rescans. The only
thing I can think of is device/driver binding, which isn't handled in
our kernel thread anyway (except where it's a new device being detected,
as opposed to a new driver being loaded).
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
-
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]
