Absolutely un-true.  With your example of the sparc, simply translate the 
   in-core BSD disklabel into a SunOS disklabel and write it.  The reverse 
   already happens at read time.  While it is true that the BSD disklabel 
   carries other information, there is likely spare space in the SunOS 
   label *somewhere*...you just keep the extra information there, and grab 
   it as appropriate at read time.  If there is no spare space, then what's 
   the difference compared to what you already have?

right.  i've written code for the sparc port to allow it to write
sunos disklabels.  i think it didn't work last i looked at it...  :-)
i'm fairly sure there isn't spare space on the sunosdisklabel,
however...but i don't remember this being a problem..
   
    > compatability with native OS disk labels on most platforms.  For
    > example, NetBSD/sparc uses SunOS-compatible disk labels, but a pack
    > with an fdisk-style partition table on it for NetBSD/i386 will perforce
    > not have a valid SunOS disk label for NetBSD/sparc.  You would have to
    > special-case every port to know about every other port's disk labeling
    > schemes.
   
   Not every port.  You bring it out into the MI layer so that everyone can 
   use it...

netbsd/sparc can read netbsd disklabels of course.    it's only for
port's like the sparc port that are forced to use non-native labels
that need the code to handle other formats.  if this code was taken
from the arch/ tree and put elsewhere for all to use...

so, who is going to do it...  :-)

.mrg.