[referring to machines reading "alien" disk packs]
>> Extremely unlikely to happen, because it is bound to break
> 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.

The point was not that you couldn't write SunOS disklabels.  The point
is that a SunOS disklabel occupies the same space that other vendor-OS
disklabels do, and thus a pack could not simultaneously have (say) a
valid SunOS label _and_ a valid DOS partition table.

Thus, the only way any disk pack could possibly work on both
NetBSD/sparc and NetBSD/i386 would be if either (a) one of them
understands the other's disk label or (b) the pack is labeled with some
third label format that both understand.  Neither is impossible, of
course.

But as long as NetBSD/sparc insists on SunOS-compatible disk labels,
and NetBSD/i386 insists on DOS-compatible disk labels, it cannot be
done.  (I do not know whether either of those has "insists" has yet
been relaxed.)

Unless, of course, by an incredibly fortuitous coincidence, there
happens to be some bit pattern that is both a valid SunOS-compatiable
label and a valid DOS-compatiable label.  I feel quite certain this
cannot be counted on in general, even if it may be possible to
construct such a bit pattern.

Or unless I'm wrong about SunOS and DOS both wanting to have stuff in
sector 0, which would invalidate the SunOS/DOS comparison but not the
general argument.

Of course, if disk labels are generalized so that each port understands
all vendor label formats, then packs become portable to other NetBSD
systems, though they would need re-labeling to be compatible with
vendor software (eg, as boot packs).

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu