Re: [PATCH 0/2] sg_ring: Gentler scsi merge

[Boaz Harrosh <bharrosh@panasas.com>]

On Thu, Jan 03 2008 at 9:00 +0200, Rusty Russell <rusty@rustcorp.com.au> wrote:
> OK, after wading through many scsi drivers, I decided to change tack and try 
> to provide a transition path.  This is in two stages:
> 
> 1) These two patches.  sg_ring used underneath, but if any driver asks for 
> scsi_sglist() they get a 2.6.24-style chained sg.  No other patches are 
> necessary.
> 
> 2) Once all chained-sg-needing scsi drivers change to use cmd->sg (ie. 
> sg_ring) directly, and the chained sg patches can be reverted.  scsi_sglist() 
> and scsi_sg_count() then become:
> 
> 	/* You should only use these if you never need chained sgs */
> 	static inline struct scatterlist *scsi_sglist(struct scsi_cmd *cmd)
> 	{
> 		BUG_ON(!list_empty(&cmd->sg->list));
> 		return &cmd->sg->sg[0];
> 	}
> 
> 	static unsigned int scsi_sg_count(struct scsi_cmd *cmd)
> 	{
> 		if (!cmd->sg)
> 			return 0;
> 		BUG_ON(!list_empty(&cmd->sg->list));
> 		return cmd->sg->num;
> 	}
> 
> Thanks,
> Rusty.

Look in the mailing list archives for the scsi_sgtable patches.
These did exactly what you do here. (OK 95% ;))
(only as a scsi subsystem not as a generic sg)

Boaz