(I tried to send this a few days ago, but the sending died and I didn't
see the message)

I'm working on a revised version of the installboot program for port
macppc, which I will release soon. Note it will be on just the -current
branch, not the 1.5_ALPHA branch, and it will need testing! :-)

Once this is working, macppc will be able to live with Apple partitioned
disks much more readily. At the same time, mac68k is talking about using
sysinst to set up the disks. So we'll be using/manipulating Apple
partition maps under NetBSD much more so than we have in the past.

Some of the weak edges of our Apple partition map are starting to
show. This handling dates to the Alice project, a project to get 386BSD
running on a Mac II. This code probably dates to before the Alice group
switched to NetBSD. :-) This code was written to be comatible with A/UX.

In the mean time, there have been changes which our Apple partition map
handling hasn't kept up with. Like how now folks make more than just 8k/1k
ffs file systems.

To adapt, we need to make two sets of changes:

1) We need to store the block, fragment, and Cylinder per group numbers.
When I was at NASA, we made some 32k/4k file systems for performance. It
was really helpful to be able to have those values stored in the
disklabel. There are a number of unused bytes in the BlockZeroBlock, the
bzb, which is space in the partition entry used by A/UX, NetBSD, and the
linuxes. NetBSD uses a few more flags than do the linuxes.

I propose we use some of the unused bytes off the end to store the needed
values (which are a uint32_t, a uint16_t, and a uint8_t), and to add a
flag indicating these values are valid. If any of the other OS's have used
fields off the end, I'd like to make sure we don't stomp on them. :-)

2) We need to be able to describe more than just an ffs. NetBSD has 21
different partition type codes which can live in a disklabel. I think that
very few of them make sense for an Apple partitioned disk. Certainly the
historical ones (V6, V7, SystemV, etc.) don't make sense. Nor do I think
AmigaDOS, FILECORE, NTFS, and the OS/2 fs make sense. :-)

The ones which definitly need support are lfs, ccd, and raid.

There are two ways we could do this. One would be to make NetBSD_LFS,
NetBSD_CCD, and NetBSD_RAID partition names. Another would be to add one
new NetBSD partition type, and have the partition type code stored in
there.

Thoughts?

Take care,

Bill