Date:        Tue, 11 Nov 2003 11:35:19 -0800
    From:        Bill Studenmund <wrstuden@NetBSD.org>
    Message-ID:  <20031111193519.GA12850@netbsd.org>

  | Luke, you're assuming the two can coexist. Apple partition maps take up=20
  | enough space in each block that we can't fit a NetBSD disklabel in=20
  | there(*).

This may seem weird, but can't the NetBSD label just go in some
other block?   There must be some blocks on the drive that NetBSD
can write in, or no-one would want a NetBSD label there in the
first place.

I understand the attraction of having the kernel write labels, rather
that user code, but I'm not sure how that's supposed to work when
drives are moved from system to system - different architectures, and
we really want NetBSD to be able to find, use, and update, the drive
contents, regardless of which system the drive is currently connected to.

That is, how would you expect things to work if you take that drive
with an apple partition map and plug it into a NetBSD alpha, or sparc,
or something?   It should all "just work" if the NetBSD label system
is working rationally, shouldn't it?    And "just work" includes
updating the partition info - even making a new filesystem, and then
moving the drive back to the apple system.

I don't think I really want the kernel having code that can deal with
all the different types of label schemes that can possibly exist - but
I certainly don't mind having a disklabel command that can manage it
(even with every possible format included, and special case coded needed
to handle all the wild things, like sun's cylinder number only label
format, the process isn't going to get any bigger than your average
modern shell or screen editor).

kre