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

[Christoph Hellwig]

On Thu, Oct 07, 2004 at 06:03:36PM -0400, Mark Lord wrote:
> (Christoph Hellwig wrote:
>  >
> >  - the !dev case in qs_scsi_queuecomman can't happen
> 
> Are you sure?
> I have seen it occur immediately after hot-removal
> of a drive.  There have been other structural changes
> since then, so perhaps it is no longer possible,
> but I'd rather have the test there than have the
> kernel ooops again.  If you feel strongly about it,
> then away it goes.

Hmm.  It's freed in ->slave_destroy and the scsi state model shouldn't
allow new command submission long before.  If you still see it happen
please send a bugreport to linux-scsi.

> >  - never mess with eh_timeout from inside a driver
> 
> Give us an interface for it, please.
> In the meanwhile, gone!

set scsi_device->timeout in ->slave_alloc to the value you want.

> >  - please don't implemente the HDIO_ ioctls, Jeff said this can
> >    be done via SG_IO
> 
> SG_IO is incompatible with current user-mode toolsets.
> Once that interface becomes more mature, and the distributions
> gradually get updated with newer versions of the tools,
> then the HDIO_ stuff can go (as per the comments in the source).
> For now, it is essential for hdparm and smartmontools, among others.
> 
> Alternatively, as Jeff has suggested, we may be able to implement
> a generic HDIO_ mechanism in libata that re-issues the commands
> through SG_IO (perhaps that is what you meant).  Is that there now?

So please fixup userspace.  New hardware will require new system tools
once in a while.

> >  - if ->info return a static string you can just store it into ->name
> 
> So just nuke the _info() proc, and use .name = QS_DESC ?
> Okay, done.

Yes.

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