NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

bin/42357: Hosted disklabel has endian issues when cross compiling.



>Number:         42357
>Category:       bin
>Synopsis:       Hosted disklabel has endian issues when cross compiling.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 21 20:45:00 +0000 2009
>Originator:     Lloyd Parkes
>Release:        5.99.12
>Organization:
Must Have Coffee
>Environment:
Darwin inspirit.must-have-coffee.gen.nz 9.8.0 Darwin Kernel Version 9.8.0: Wed 
Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh
Source tree is -current dated "31 May 2009 00:00 +1200"
>Description:
Our disklabel assumes that the host and target endianness is the same (even 
though it understands that they may not be the same platform). Therefore, when 
I build NetBSD/i386 disk images on my PowerMac G5 running OS X, disklabel 
writes an incorrect label to the images.
>How-To-Repeat:
Create a large empty file on a big endian machine, label it with a hosted 
disklabel (i.e. $TOOLDIR/bin/nbdisklabel-i386) and then copy it onto a CF card 
or USB drive. You will find that NetBSD/i386 is unable to find the disklabel 
you put on it, even though $TOOLDIR/bin/nbdisklabel-i386 can find it just fine.
>Fix:
A patch is at
http://home.must-have-coffee.gen.nz/svn/software/miniaturise/disklabel.patch

This adds a function called bswap_label() that byte swaps a label and some 
calls to that function. The dkcksum function has been changed to take the 
number of partitions in the label as a parameter because it sometimes needs to 
checksum a byte swapped label. I could have changed dkcksum to check the label 
magic numbers and byte swap the npartitions field if necessary, but that would 
have introduced a lot of new dependencies to dkcksum, so I opted for the extra 
parameter.

I also replaced a couple of u_short with uint16_t because we are dealing with 
data types whose size is fixed externally. (u_short may be defined to have a 
fixed size, but there's no harm in saying what you mean.)



Home | Main Index | Thread Index | Old Index