On Sun, Nov 09, 2003 at 07:37:53PM +0100, Hauke Fath wrote:
  | At 1:49 Uhr +0900 10.11.2003, Izumi Tsutsui wrote:
  | >In article <l03102800bbd4175d6bdf@172.16.7.4>
  | >hauke@Espresso.Rhein-Neckar.DE wrote:
  | >
  | >> >May I humbly ask you to note that on some ports (at least amiga, amigappc
  | >> >but ISTR that atari? is similar) we don't use any NetBSD disklabel?
  | >>
  | >> Add mac68k and macppc here.
  | >
  | >No, macppc could have NetBSD disklabel.
  | >(wd0 on my old macppc doesn't have Apple partition map.)
  | 
  | Sure, but you definitely do not want to blow away an Apple partition map
  | and replace it with a NetBSD disklabel, even if the disklabel gets the
  | partitions right.

Does the raw label share the same location on the disk as the
"native platform" label?  If so, that's a design flaw in that
port's choice of LABELSECTOR/LABELOFFSET.

(The reason i386 has the label at offset 512 instead of 64 like
most other platforms is because the first 512 bytes is used for
the "native" master/partition boot record.  I don't understand
why other platforms didn't make the same choice.)

The argument for doing all of the "raw" label manipulation via
DIOCWDINFO means that the port specific implementation of that
ioctl can decide what & where it need to write.  For example, on
the sparc, it can write the NetBSD label to the approriate part of
the disk, and then the translated ``fake''Sun ("PROM") label as
well.

Or are there some platforms which always fake up the incore NetBSD
disklabel from the "native" partition map at boot, and don't actually
have a copy of the NetBSD partition map stored on the disk?
If so, DIOCWDINFO can just treat the raw label write as a no-op,
and we provide [host buildable] native partition maninpulation tools
for those platforms (a la fdisk(8) or pdisk(8)).

In any case, disklabel(8) shouldn't be doing the work of manually
writing the raw disklabel to the disk with read(2)/write(2), and
I still haven't seen a good case yet to why it should continue to
support that.