Re: [RFC] IBM Power RAID driver (ipr)

[Christoph Hellwig <hch@infradead.org>]

On Tue, Jan 20, 2004 at 10:41:12AM -0600, Brian King wrote:
> > Please do.  Also what about making this and the above one conditional on
> > some debugging option?
> 
> How about a kernel config option for this? I don't want to make it too 
> difficult for people to enable it as it is exceedingly valuable for 
> failure analysis.

Yes, that's what I meant.

> > Given all the mess these invisble devices create I think they shouldn't
> > be invisble but rather exported as a second pseudo-channel on the host.
> 
> Ok. That would solve a lot of problems. I will report these devices in 
> as scsi disk devices. They will respond like normal SCSI disks, except 
> when issued media commands (read/write) it will fail with data protect 
> (07) sense data.

Now reading this again it might be better to use the "fake" as in not
registered with the device model devices I mentioned below for this.

> Yes. Should be able to. By getting rid of all this code, one problem we 
> will need to solve is the following:
> 
> 1. Driver is up and running with a disk array.
> 2. Adapter gets reset for some reason (could be due to an adapter error)
> 3. Disk array device now needs a START_UNIT command.
> 
> The current mid-layer/sd will not handle this. Would you accept a patch 
> to add this function?

I'm not against this, but I wonder how such a patch would look like

> Ok, but I will still need that interface to send commands directed to 
> the adapter.

commands as in scsi commands or as in internal commands?

> >>Build a command in DMA'able host memory (struct ipr_ioarcb), write the 
> >>PCI address to a register on the adapter, the adapter DMAs down the 
> >>control block, executes the command, writes the 
> >>ipr_ioarcb.host_response_handle in the command control block to the host 
> >>request/response queue in host memory, and signals an interrupt.
> >>
> >>Does that help at all?
> > 
> > What's the relation of all these command lists to that?
> 
> Sorry, I guess I'm missing something here. Are you saying a LLD 
> shouldn't need to maintain of queue of its command blocks (like my 
> pending_q and free_q)?

Unless you allocate the blocks in ->queuecommand (like most modern drivers
do) you'll need some form of freelist of course.  What you shouldn't need iß
the pendig_q as the midlayer already keeps track of pending commands.
This of course only works if you actually do send all commands via the
midlayer (which you should).

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html