> Don't know if anybody answered this, but the mapping changed a while back.
> The sd partition letters now only refer to the ones that are A/UX
> partitions.  MacOS partitions are skipped.  This eliminates the need for
> the A/UX stuff to be in the first 8 partitions like it used to require.
> Of course, if anybody gets in-kernel HFS working, that will have to change
> back....  There ought to be a better answer, like creating a new type, say
> hd for HFS Disk, with the same mapping scheme as the sd's use, except only
> map the HFS partitions, instead of only mapping in the A/UX partitions.
> Thoughts?

As Paul pointed out, the current system will still show MacOS partitions,
it's just supposed to be better about finding NetBSD ones.

I don't like the hd idea as that means another block device, with no
other functionality than changing partitions.

I think what we should do is fix MacOS partition disklabeling.

I've talked with a few folks about it (though neither Scott nor Allen),
and here are some of my ideas (briefly at first):

1) Make the MacOS partition reader pickier about what it puts in the
disklabel - make sure "interesting" partitions float to the top.

2) Make it so we can modify the kernel's disklabel. So if we want a
partition which is not listed but is on the disk, we change the
in-kernel disklabel so a partition we don't use now points to the one
we want. This step'd need another program (which grocked MacOS partitions)
to work right.

3) We could go to 16 partitions / drive. The amiga port already has.

4) We could actually start WRITING disklabels for the MacOS case! The
Mac's partitioning format certainly can deal with multiple kinds of
partitions, so adding a "NetBSD partition table" partition type is
no big deal.

5) We could actually start changing MacOS partitoins. :-)

More details:

3) (first since it's easiest) Going to 16 partitions is no big
deal. The only problem is that the kernel and /dev must agree. I don't
know how the Amiga port switched, but we could just read /dev/sd1a
off of the root device (say just before really mounting the root device)
and see what its minor # is. We'll either get minor 8, minor 16 (both
of which say how many partitions sd's have), some other # we'll
accept as a # of partitions, or garbage. If we get garbage, well, the
system's not going to live long if root's not sd0. If root's on sd0,
someone might have a system with only a small drive and decided there's
not enough space for device special files. :-) We can fall back to
8 in that case.

1) My thought was to prioritize things, search the partition table and
rank everything, then fill in the blanks according to what's found.

My priority'd be:

i:	"root" named in the booter (to "a")
ii:	first swap (to "b")
iii:	first "usr" partition (to "g")
iv:	Next 3 "root" or "usr" partitions
v:	3 MacOS partitions
vi:	Other "root", "usr" or MacOS partitions
vii:	Anything else

Basically we try to get a variety of "interesting" partitions to use.

2) Make the in-kernel disklabel mean something. When we first read the
label, we use the above algorythm. Then we can change the layout over
time. If we are updating the kernel copy, we note differences. (if
the disk partitions are read-only) You would only be able to change a
partition if: (1) it's not open right now, and (2) the new partition
corresponds to an actual on-disk partition.

Thus if you have a LOT of partitions, you can see the ones you want.

4) Adding a partition with a NetBSD disklabel is not a big deal. We
just look for such a beast on boot, and update it as needed. That way
we can save a customized idea of what partitions we want where.

Unix usually puts this in the front of partition a, but AFAIK that's
because UNIX did all the formatting in the disklabel, and you had to
put the table somewhere. For a MacOS disklabelded drive (not a NetBSD
disklabeled drive), we must keep the MacOS partitions around, so
why not use them?

5) We can do cool stuff if we choose to write MacOS partitions. Note:
This isn't the same as having a NetBSD partition table. Here, we can
change MacOS partitions. If the disklabel overlaps only one existing
not-open partition, then we just grow the existing partition,
posably moving the start too. If the partition doesn't exist (overlaps
no partitions) and we can add a partition to the table (maybe killing
a "free" partition), we add it. If it overlaps two partitions, we
complain.

I'd hoped to add this code soon, but it looks like I won't. Sorry. :-(

Take care,

Bill