On Thu, Jan 03 2008 at 9:00 +0200, Rusty Russell <rusty@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
