Re: [PATCH 3/3] Import fw-sbp2 driver.

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Jeff Garzik wrote:
> Kristian Høgsberg wrote:
>> +struct sbp2_status {
>> +    unsigned int orb_high:16;
> 
> unsigned short?  probably generates better code than a bitfield:16
> 
> 
>> +    unsigned int sbp_status:8;
> 
> unsigned char?
> 
> 
>> +    unsigned int len:3;
>> +    unsigned int dead:1;
>> +    unsigned int response:2;
>> +    unsigned int source:2;
>> +    u32 orb_low;
>> +    u8 data[24];
>> +};

This as well as ORBs and responses are series of u32 that go in or out
in big endian byte order.

The old FireWire drivers have two styles to deal with such data
structures: Define them as a struct or array of u32 and manipulate bits
by arithmetic expressions, or define them as bitfields similarly to what
you see above. Of course either approach has to account for host byte
order in one or another way.

...
>> +
>> +    /* FIXME: Make this work for multi-lun devices. */
>> +    lun = 0;
> 
> doesn't allowing the stack to issue REPORT LUNS take care of this?

SBP-2 LUs and their LUNs are obtained from the ISO/IEC 13213
configuration ROM of the target.

The FIXME comment is misleadingly worded, at least as far as the "old"
sbp2 driver is concerned, which AFAIU served as a starting point for
fw-sbp2. The sbp2 driver supports multi-unit targets; it just represents
each LU behind an own Scsi_Host. This had several reasons, most of them
historic now. I am considering to make sbp2 use a single Scsi_Host for
all its LUs and perhaps join LUs of the same target beneath a single
scsi_target. But this project doesn't have priority for me.
-- 
Stefan Richter
-=====-=-==- ==-- --=-=
http://arcgraph.de/sr/