On Thu, Jan 03 2008 at 9:00 +0200, Rusty Russell <[EMAIL PROTECTED]> 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

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

Reply via email to