Re: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3

[Mark Lord <lkml@rtr.ca>]

James Bottomley wrote:
>
> Actually, the driver has no need for a thread at all.  Since you're
> simply using it to fire hotplug events, use schedule_work instead.

That worries me some, because the mid-layer will perform blocking I/O
and the like, and I'm not sure how much that stuff may depend on its
own usage (any?) of workqueues.  If you believe it to be safe,
then I'll nuke the kthread entirely.

> I also noticed the following in a lightening review:
> 
> - Kill these constructs:
> +	/* scsi_done expects to be called while locked */
> +	if (!in_interrupt())
> +		spin_lock_irqsave(uhba->lock, flags);
> 
> scsi_done() doesn't require a lock

Really?  I wonder why the mid-layer is so religious about
doing the lock around every invocation of it today?

But again, if we're sure that this is the case, then it certainly
make's life simpler in the driver.

> - Your emulated commands assume they're non-sg and issued through the
> kernel (i.e. you don't kmap and you don't do SG).  This will blow up on
> the first inquiry submitted via SG_IO for instance.

The SG is tested for and simply failed -- there is no need today for
SG usage on those code paths.  If there turns out to be a need for that
interface with this driver in the future, we can add it.  Just like most
of the other drivers currently treat it.

What is the "kmap" semantic, and how should it be applied here?

Thanks
-- 
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")