Re: Transport Attributes -- attempt#3

[Martin Hicks <mort@bork.org>]

On Wed, Jan 14, 2004 at 03:34:57PM -0800, Andrew Vasquez wrote:
> On Wed, 14 Jan 2004, Martin Hicks wrote:
> 
> > +
> > +/* the FiberChannel Tranport Attributes: */
> > +fc_transport_rd_attr_cast(node_name, "0x%llx\n", unsigned long long);
> > +fc_transport_rd_attr_cast(port_name, "0x%llx\n", unsigned long long);
> > +fc_transport_rd_attr(port_id, "0x%x\n");
> > +
> 
> Purely aesthetics : PortIDs are typically viewed as three hex bytes
> padded with zeros, i.e. 010203.  Perhaps this may be more appropriate:
> 
> 	fc_transport_rd_attr(port_id, "0x%06x\n");

Okay.  Will do.

> 
> [snip]
> > +	attrs = (struct fc_transport_attrs *)sdev->transport_attr_values;
> > +	list_for_each_entry(fc, &ha->fcports, list) {
> > +		if (fc->os_target_id == sdev->id) {
> > +			attrs->port_name = __be64_to_cpu(*(uint64_t *)fc->port_name);
> > +			attrs->node_name = __be64_to_cpu(*(uint64_t *)fc->node_name);
> > +			attrs->port_id = fc->d_id.b24;
> 
> This port_id assignment will not give you what you expect on
> big-endian machines.  Given the previous port_id example value
> (010203), on BE machines, the attribute will read as 030201 when
> displayed.  A more endian safe way if you want to continue with the
> pure-type usages (uint64_t/int) rather than byte arrays would be:
> 
> 	attrs->port_id = fc->d_id.b.domain << 16 |
> 		fc->d_id.b.area << 8 |
> 		fc->d_id.b.al_pa;

I'll fix that up.

Thanks,
mh

-- 
Martin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE