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

[James Bottomley]

On Fri, 2004-10-08 at 10:15, Mark Lord 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.

We use this already for other entities that require user context like
domain validation.  It seems to work as advertised.

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

It's not if you look at other drivers.  There's no harm in taking the
lock, so none of the old ones got updated, but the lock isn't needed. 
The idea is that if you're holding the lock naturally (say in an
interrupt routine) there's no need to drop it artificially.  However,
you definitely shouldn't take it artificially like you do.

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

And you've tested this with things like SUSE's hwinfo utility which
seems to send INQUIRIES on its own?

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

kmap is used to make a user page visible to the kernel.

Really, I suppose, libata should provide the interfaces for doing this
work for emulated commands.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/