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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/