ok, what's the official take on "endianness"? and hdparm problem

[Tito]

On Tuesday 6 June 2006 22:11, Ken McGuire wrote:
> On 6 Jun 2006 at 15:13, Rob Landley wrote:
> 
> > On Thursday 01 June 2006 1:46 pm, Robert P. J. Day wrote:
> > >   probably a silly question, but what's the whole story on best
> > > practises for dealing with endianness?
> > 
> > We recently grew better support for endianness in platform.h.
> > 
> > We define BB_BIG_ENDIAN and BB_LITTLE_ENDIAN, each of which is true or false 
> > depending on the current platform.
> > 
> > We also have six macros: SWAP_BE16(), SWAP_BE32(), SWAP_BE64(), SWAP_LE16(), 
> > SWAP_LE32(), and SWAP_LE64().  Each of these returns the modified data (if 
> > you want to convert in place, assign it back to itself.)  Use these when you 
> > know the data is in a given format, so:
> > 
> > uint32_t external;
> > 
> > external = SWAP_LE32(external);
> > external += 42;
> > external = SWAP_LE32(external);
> > 
> > On a little-endian system, the swap is a NOP, and the assignment to itself 
> > gets optimized away.  On a big-endian system, it should swap before doing the 
> > addition, and then swap it back afterwards.
> > 
> > > rday
> > 
> > Rob
> > -- 
> > Never bet against the cheap plastic solution.
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> > 
> 
> Rob,
> I think I have found where the problem with hdparm is when running on my ppc 
> system. To review; iBook ppc G3 running ubuntu 5.10, gcc 4.0.2  busybox svn 
> 15284. hdparm -I /dev/hda produces incorrect results which appear to be an 
> endian problem.
> 
> I poked around in hdparm.c and found the nice new macros described below. I 
> also found this in "identify()":
> 
> 	if (BB_BIG_ENDIAN) {
> 		swab(id_supplied, buf, sizeof(buf));
> 		val = buf;
> 	} else val = id_supplied; 
> 
> 
>  Even with the nice new macros, hdparm still produced the same errors as in 
> earlier versions (svn 15237). I removed the above test and the busybox hdparm 
> now produces the same result as the ubuntu hdparm (v6.1) I have attached a 
> patch for this, but have only tested it on one ppc system so far. There also 
> may be some other cleanup that you might want to do as gcc reports that buf[] 
> is now unused.
>    ...ken...
In fact in newer hdparm code this test is gone.
From hdparm 6.6+:

void identify (__u16 *id_supplied)
{

	__u16 val[256], ii, jj, kk;
	__u16 like_std = 1, std = 0, min_std = 0xffff;
	__u16 dev = NO_DEV, eqpt = NO_DEV;
	__u8  have_mode = 0, err_dma = 0;
	__u8  chksum = 0;
	__u32 ll, mm, nn;
	__u64 bb, bbbig; /* (:) */
	int transport;

	memcpy(val, id_supplied, sizeof(val));

	/* calculate checksum over all bytes */
	for(ii = GEN_CONFIG; ii<=INTEGRITY; ii++) {
		chksum += val[ii] + (val[ii] >> 8);
	}

	/* check if we recognise the device type */
	printf("\n");

	if(!(val[GEN_CONFIG] & NOT_ATA)) {
		dev = ATA_DEV;


Ciao,
Tito
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>