Re: [PATCH] kthread conversion: convert ieee1394 from kernel_thread

[Ben Collins <bcollins@ubuntu.com>]

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 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/