Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley <James.Bottomley@SteelEye.com>]

On Sun, 2005-07-10 at 00:36 -0400, Ben Collins wrote:
> I would have to say that it isn't working for a lot of people. Why does
> our code work for everything, but the scsi code only work for some ppl?
> Atleast I can say that where things are broken, our code fixes it, and
> where things are working, our code also works. It would seem our code has
> a workaround for the cases where the scsi code doesn't.

Could we have a few bug reports to try to diagnose, please?

> One thing that stands out is that we have a bit of code that changed the
> device type from TYPE_RBC to TYPE_DISK in the command structure. Since I
> didn't write this code, I can't really say why that is.  Any ideas what
> that was trying to accomplish? I've attached the changes here, so you can
> see what our code did and maybe make some sense of it.
> 
> I honestly thing that our code was removed in an attempt to replace it
> with some common code, perhaps without fully understanding what it may
> have done special. I have to say, after looking at the scsi code that
> replaces the sbp2 code, I can't see a hole lot of similarity.

What the code you attached does is

1) Convert READ_6 and WRITE_6 into READ_10 and WRITE_10 (RBC devices
only use 10 byte commands).  The equivalent functionality is achieved by
setting sdev->use_10_for_rw in slave configure.

2) Convert MODE_SENSE into MODE_SENSE_10.  The equivalent functionality
is achieved by setting sdev->use_10_for_ms in slave configure.

3) Massage the value of MODE_SENSE_10 returns slightly.  RBC devices
have a few small differences in the way they present mode sense
information.  The changes in sd.c account for this.

So, for RBC devices, the changes look equivalent.

The only possibility for a problem might be that the code you quote
massages the MODE_SENSE data for every device, whereas the SCSI changes
only do it for RBC devices ... are the devices reporting difficulties
non-RBC?

James