Jeff Garzik wrote:
> Two comments:
>
> 1) CONFIG_CISS_SCSI_TAPE should be CONFIG_CCISS_SCSI_TAPE, IMO
>
> 2) is any locking needed in your scsi eh reset handlers? recent
> kernels eliminate the lock that's been traditionally held around
> the handlers.
About the locking first,
So, there's one part that I was a little worried about, where
it does this in a couple places:
c = (ctlr_info_t **) &scsicmd->device->host->hostdata[0];
(gets our adapter structure by following pointers in the scsi
command)
So, if that pointer chain can change suddenly, then my code is bad.
Can doing "echo scsi remove-single-device . . . > /proc/scsi/scsi"
cause that pointer chain to break? I noticed I can yank a disk
out from under a mounted filesystem with
"echo scsi remove-single-device" It wasn't obvious to me whether
doing that would affect that pointer chain though, though I could
imagine it might.
Or am I barking up the wrong tree worrying about
the scsicmd->device->host->hostdata pointer chain
getting yanked out from under me?
Apart from possibly the two places where I do that,
I think it's ok.
About the CONFIG_CISS_SCSI_TAPE, we can change that, although
it's been that way for years, and was following the
BLK_CPQ_CISS_DA which was there since the drivers inception.
Does it unnecessarily break people's existing .config files?
(not badly of course.)
-- steve
-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Fri 11/11/2005 5:36 AM
To: Miller, Mike (OS Dev)
Cc: [email protected]; [email protected]; [email protected]; Cameron, Steve
Subject: Re: [PATCH 1/1] cciss: scsi error handling
[email protected] wrote:
> PATCH 1 of 1
>
> This patch adds SCSI error handling code to the SCSI portion
> of the cciss driver.
>
> Signed-off-by: Stephen M. Cameron <[email protected]>
> Acked-by: Mike Miller <[email protected]>
> +#ifdef CONFIG_CISS_SCSI_TAPE
Two comments:
1) CONFIG_CISS_SCSI_TAPE should be CONFIG_CCISS_SCSI_TAPE, IMO
2) is any locking needed in your scsi eh reset handlers? recent kernels
eliminate the lock that's been traditionally held around the handlers.
Jeff
-
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]
