Bill Studenmund wrote:

>I think the idea is that the fake map has a partition map in blocks 1 & 2,
>and the boot code starting at block 4. The size of the driver block is
>definitly wrong, and will be fixable if we know stats on the disk.
>
All blocks on the disk other than Block0 are supposed to be described by 
an entry in the Parition Map though according to Apple Docs.  So there 
really should be a Map Entry which describes the boot code like what 
you're now doing.  ;-)

>Oh, what I was saying is that the partition map starts at block 1, but
>that the partition map entry doesn't have to be the first. The current
>code searches the partition map for the entry which covers the map itself.
>
Good!  We'll be in a much better position to use disks that were 
previously setup by a variety of disk formatters then.

>Another option is that I think he has the ability to add drivers to the
>image. We could just have mkhybrid add a dummy (well incorrect) bootxx
>image, and then use installboot to fix things later.
>
Right now the boot option in mkhybrid relies on a fixed format that 
appears to be designed to only handle MacOS boot requirements.  There's a 
small utility that one uses to pull the boot code from a working disk in 
a format that is acceptable to mkhybrid, and that format doesn't match 
what we probably want to do for NetBSD.  That's why I was working on 
"mkmacbootcd".

>Note: this version of installboot doesn't do the right thing for
>non-512-byte blocks!
>
Shouldn't be a problem until we get to CDs and by then maybe we'll have 
something the Start Manager can deal with.

>> >What are these blocks allocated to???
>> >
>> They aren't! And that's the problem.  The block are technically allocated 
>> to the Partition Map, but since the pmPartBlkCnt/pmDataCnt values dont' 
>> correctly map the entire space allocated they appear to be unallocated.  
>> However if one tries to re-partition the disk most disk formatters will 
>> correctly assume the space should be allocated to the Partition Map and 
>> use it.
>
>?? If they aren't in the partition map, they aren't allocated. :-)
>
>Weird...
>
Yes, these are blocks that appear to be wedged in between the Partition 
Map and the first partition on disk which violates the requirment that 
all blocks on the disk are described by a Map Entry.  Many formatters 
will just assume these are blocks allocated to the Map Partition but are 
unused and will attempt to use them when re-partitioning the disk. One 
disk formatter I've looked at actually uses all the blocks in the Map in 
a round-robbin fashion, i.e. it doesn't look for an unused block at the 
front of the map as long as there appear to be unused blocks in the Map 
beyond the current block.

>> >I thought about Apple_Scratch, but decided against it for now.
>> >
>> No problem, just wanted to make sure you were aware that it exists with 
>> some formatters.
>
>Right. I just wasn't sure if it was really "free" space. :-)

I've never found anything that used these partitions or that documented 
their use. I have found a couple of disk formatters that treat them as 
free space and that's what I did in sysinst/mac68k.

-bob