On Wed, 16 Aug 2000, Bob Nestor wrote:

> Bill Studenmund wrote:
> 
> >I tested this code to make sure it compiled. I have not actually used it.
> >Use with caution!
> >
> While I haven't run the code (my system is trashed right now due to a 
> MacOS crash), I did notice some things that might be of interest.

Cool! That's what I wanted!

> >We now go into the partiton map groveling even if we have the -n flag. We
> >won't write anything (partition is opened r/o), but we will look at what's
> >around. Can be combined with the -v flag to see what will be done.
> >
> There are some errors in the way the fake APM is configured right now.  
> The disk size isn't correct and the APM has some minor errors in it.  I 
> don't know if you want to fix these along the way or if it's even 
> important to do so at this time.  The only reason I found them is that I 
> relied on some of these fields in sysinst/mac68k.

Yes, I'd like to actually store the right number of blocks in there. I
haven't added that yet, as it means grabbing the disklabel to get disk
info.

What else is wrong?

> I noticed the #define's for the most common partition types.  The list 
> isn't completely defined in NetBSD at the moment. There are driver 
> partition types defined for ATA, ATAPI, and CDROM drivers that I've found 
> looking at a number of disks and CDs.  Also these names are all 
> case-insensitive although one gets the impression from reading Apple's 
> docs that they are all upper-case.  This was a problem for Mkfs on the 
> 68k port a few years ago.

I got the impression they were mixed-case. Hmm... If you have more, that'd
be great!

> The Partition Entry usually starts in block 1, but you can't count on 
> this!  There are many disk formatters that scramble the blocks in the 
> Partition Map and I've found that I always had to hunt for the entry that 
> mapped the Partition Table itself.  Some disk formatters and disk setup 
> routines improperly initialize the size of the Partition Table to be just 
> the number of blocks used rather than the number allocated as the 
> documentation calls for.  Mkhybrid is guilty of this error.  I've found 

Well, since the partition map mkhybrid uses won't grow, that's not too
bad.. We might want a partition editor which will fix these errors.

> that it's best to scan for the lowest allocated partition which is 
> adjacent to the Map to determine the actual size of the Partition Map. 
> (Apple docs indicate that all blocks on a disk are mapped by the 
> Parititon Map except for Block0.) The other thing that many disk 
> formatters do, which is incorrect, is to hide boot code in blocks in the 
> Partition Map that are allocated but unused.  Apple even does this on 
> some of their CDs in violation of their documentation.  Its not a problem 
> on CDRs since the CD can't be modifed, but on a disk it can be a 
> disaster.  It makes disk partitioning a real headache since the process 
> can end up destroying disk boot code!

What are these blocks allocated to???

> >If we find an "Apple_Free" partition, we found freespace. If it is big
> >enough to hold the boot blocks and either we haven't found a free space
> >partition yet, or this one is smaller than the one we already found, we
> >use it.
> >
> Other partition types that might also qualify are "Apple_Scratch" and 
> "Apple_Unused".  Both are present in some disk formatters.

I thought about Apple_Scratch, but decided against it for now.

> >Then we get the freespace partition we're using. We strip space out of it,
> >and save it. We then itterate over all partitions increasing the count of
> >active partitions.
> >
> I haven't looked real close at the code yet, but I assume by "strip 
> space" you mean allocating a part of the free space.  Do you create a new 
> partition map entry to place the rest of the space in, i.e. do you 
> "split" the original partition into two entries?

Actually I remove space from the front of the existing Apple_Free
partition, and I use that space in the NetBSD/macppc partition I add at
the end of the map.

Take care,

Bill