On Tue, Feb 28, 2006 at 02:10:34PM -0500, Doug Fraser wrote:
> 
> This has to do with disk labels in general.The file system (FFS) supports
> endianness independence if so configured,and the newfs command supports
> specific endianness by specifying -B le or -B beIt appears that the
> disklabel, however, is platform specific.I would like to move PCMCIA disks
> between i386 and PowerPC hosts, and Ihave made some initial changes to
> support this locally.  Before I make a largenumber of changes to support
> this fully, is there any specific reason that thiswas avoided in the current
> scheme of things? Is there any reason that using adefault of little endian
> for disklabels would be bad?Also, though there is a lib/disklabel with a
> couple of functions defined there,there are a few other instances (for
> example dkcksum) which are scatteredas identical copies throughout the
> source tree.My proposal is to provide a void localdisklabel(struct disklabel
> * lbl) that properlyswaps each element in the structure using appropriate
> le16toh() and le32toh() calls.I have do > ne this with the disklabel command
> and it is working now.The point being that if you convert it immediately
> after reading and again immediatelybefore writing, then the intervening use
> of the structure does not require conversion.Any thoughts?Douglas Fraser >

Byteswapping disklabels would help, but the kernel would have to be very
careful not to write the byteswapped label back to the media.
There are good reasons why the label is in native endianness, however a
byteswapped label can be detected because the maigic numbers are reversed.

A first step might be to byteswap byteswapped labels in disklabel(8)

	David

-- 
David Laight: david@l8s.co.uk