[PATCH] hdparm size reduction

Rob Landley rob at landley.net
Tue May 2 13:47:51 PDT 2006


On Tuesday 02 May 2006 7:50 am, Tito wrote:
> the last version of hdparm just ripped out the dead code
>
> and reinserted the checksumming:
> > > 	/* calculate checksum over all bytes */
> > > 	for(ii = GEN_CONFIG; ii<=INTEGRITY; ii++) {
> > > 		chksum += val[ii] + (val[ii] >> 8);
> > > 	}

This is what the mainstream hdparm is doing, then?

Not much of a chksum, is it?

> Maybe we can try, but later on in the code we have this checks to match:
>
> 		else if (((std == 4) || (!std && (like_std < 5))) &&
> 			((((val[INTEGRITY]	& SIG) == SIG_VAL) && !chksum) ||
> 			((	val[HWRST_RSLT] & VALID) == VALID_VAL) ||
> 			(((	val[CMDS_SUPP_1] & VALID) == VALID_VAL) &&
> 			((	val[CMDS_SUPP_1] & CMDS_W83) > 0x001f)) ) )
> and
>
> 			printf("Checksum: ");
> 			if_printf(chksum,"in");
> 			printf("correct\n");
>
> so it seems we are testing for zero or non zero.

What exactly is the use case for this?  I haven't got the half-hour to read 
through this and try to untangle the logic right now.  (Bit of a mess, isn't 
it?)  What command line would trigger this output, or make a difference in 
the test?

Thirty seconds with the man page proved unrevealing.  Doesn't seem mention a 
checksum at all...

> Could this be done with the new crc32 stuff and if yes how,
> I'm willing to test it if you give me a hint how ;-)

I think the problem here is definitely a question of divining intent, rather 
than anything to do with the implementation.  (And you wonder why I prefer 
implementing sane applets from the specs or man pages, rather than porting in 
external code.  Oh well...)

Rob
-- 
Never bet against the cheap plastic solution.


More information about the busybox mailing list