Subject: disklabels
To: None <tech-misc@netbsd.org>
From: Doug Fraser <dwfraser@onebox.com>
List: tech-misc
Date: 02/28/2006 14:10:34
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------=_NextPart_001_01BF24B2.F1B80B94
Content-Type: text/plain;Charset = "iso-8859-1"


 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 


------=_NextPart_001_01BF24B2.F1B80B94
Content-Type: text/html;Charset = "iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

  <div style="font-family: Arial,Verdana,Helvetica,Sans-serif; font-size: 13px;">This has to do with disk labels in general.<br><br>The file system (FFS) supports endianness independence if so configured,<br>and the newfs command supports specific endianness by specifying -B le or -B be<br><br>It appears that the disklabel, however, is platform specific.<br><br>I would like to move PCMCIA disks between i386 and PowerPC hosts, and I<br>have made some initial changes to support this locally. Before I make a large<br>number of changes to support this fully, is there any specific reason that this<br>was avoided in the current scheme of things? Is there any reason that using a<br>default of little endian for disklabels would be bad?<br><br>Also, though there is a lib/disklabel with a couple of functions defined there,<br>there are a few other instances (for example dkcksum) which are scattered<br>as identical copies throughout the source tree.<br><br>My proposal is to provide a vo
 id localdisklabel(struct disklabel * lbl) that properly<br>swaps each element in the structure using appropriate le16toh() and le32toh() calls.<br>I have done this with the disklabel command and it is working now.<br><br>The point being that if you convert it immediately after reading and again immediately<br>before writing, then the intervening use of the structure does not require conversion.<br><br>Any thoughts?<br><br>Douglas Fraser<br><br></div>  


------=_NextPart_001_01BF24B2.F1B80B94--