On Fri, 17 Dec 1999, Bob Nestor wrote:

> Frederick Bruckman  (fb@enteract.com) wrote:
> 
> >I confess not to understand. What's the "disklabel -r" for? Doesn't

disklabel -r is for reading a NetBSD disklabel off of a disk. :-)

> >the mac68k sysinstall manipulate the native apple partition map?
> >Anything else could be very lossy on the next reboot, when MacOS
> >recognizes a different map than NetBSD. In contrast, the i386
> >sysinstall identifies and uses the _unused_ section of the disk, which
> >works well for dual boot systems.
> 
> Let me see if I can explain. It's been a couple of months since I worked 
> on code, but I think I can get most of the explaination correct without 
> digging into the code.
> 
> NetBSD has it's own idea of the format of disk labels which is MI and 
> consistent across all ports.  These labels are normally recorded on the 
> physical disk and maintained in RAM during the time a physical disk is 
> made accessible to the system.  The mac68k port does not support native 
> disk labels.  This means that the BSD style labels are not written to the 
> physical disk.  Instead when the system is booted the Apple Disk 
> Partition Map is read and a fake disk label is constructed.  This fake 
> disk label is in the format of the BSD label that other ports record 
> ondisk.  The advantage of this approach is that once the disk label is 
> faked up, the rest of NetBSD can use it in an MI manner, i.e. nothing 
> else in the kernel has to know about or deal with the Apple Partition Map.

Actually both macppc and mac68k support reading NetBSD disklabels, but
only macppc supports writing them.

> The NetBSD kernel only updates it's RAM copy of the disk label associated 
> with a physical volume when the volume first comes online, such as with a 
> system boot or with a media change, or when it knows the label has been 
> modified such as when disklabel attempts to write out the new disk label. 
>  At all other times the kernel uses it's RAM copy of the disk to remap 
> disk I/O to the proper physical areas of the disk.
> 
> When NetBSD wants to manipulate a disk label, as when trying to 
> re-partition a disk, it modifies the RAM copy of the label and then 
> writes that to the physical disk.  Actually what happens is disklabel 
> modifies a local copy of the disk label and calls on some low-level I/O 
> routines in the kernel to write them to disk and update the RAM copy that 
> the kernel uses. It does this to insure that the disk label recorded on 
> disk is always the same as the copy that is being used by the kernel.  To 
> minimize unnecessary disk I/O the kernel does not go back to the disk to 
> read the label when it needs to map a disk I/O request, instead it uses 
> the incore copy of the disk label. The order of the update of the two 
> labels is important here; the ondisk label is written first, then the 
> kernel copy of the disk label is updated. That way if the disk write 
> fails, the disk is still accessed using the previously obtained disk 
> label.

Actually the code's a bit twistier than that. I think it's quite crufty,
and needs re-work.

Under some circumstances, the disklabel program writes the sector
containing the disklabel after manually loading the new disklabel into the
kenrel. Other times, it has the kernel do the writing (I assume after
setting it using it in a codepath I missed).

> Now, since the mac68k port does not support native disk labels, i.e. 
> there is no copy of the BSD labels recorded ondisk, the disk write 
> operation fails.  It fails because it was dummied out in the kernel 
> disklabelwrite routine.  When the "disklabel" utility issues the syscall 
> to update the disk label this routine in the kernel gets called, it fails 
> (since it's been dummied out), and the RAM copy of the disk label is left 
> untouched.  All the work done by the "disklabel" utility is for naught 
> because the results didn't get written any place, and the kernel's RAM 
> copy of the disk label is unchanged.  This is actually the failure one 
> sees when trying to run disklabel to repartition a disk on the mac68k 
> port.
> 
> When I wrote the sysinst code to do the disk partitioning process I put 
> in code to directly read and update the ondisk Apple Disk Partition Map.  
> Sysinst (and your Installation Kernel in the 1.4.2-current snapshot) 
> should be able to do this, but since the kernel's copy of the disk label 
> is left unchanged it appears that  the disk partitioning process failed. 
> If the system is rebooted after this point in sysinst, one discovers that 
> the new partitions in fact do now exist.  So the missing link was to 
> convince the kernel to update it's RAM copy of the disk label which was 
> initially constructed when the kernel was booted.  I needed to force the 
> Kernel to rescan the Apple Disk Partition Map and reconstruct the faked 
> BSD disk label that in now in RAM.  My solution was to make one small 
> change to the disklabelread/disklabelwrite routine in the kernel.  Since 
> native disk labels still aren't supported the disklabelwrite call should 
> remain basically a nop, but if it then called the disklabelread routine 
> before returning, the kernel's RAM copy of the disk label would be 
> updated.  This was never done previously since the kernel knew that since 
> the disklabelwrite was dummied out the faked disklabel couldn't have 
> changed. Disklabelread does the work of building the faked disk label in 
> RAM that is used by the kernel.

Don't you at that point know which partitions are which? i.e. a) is here,
b) there, & so on? Couldn't you just set a new disklabel into the kernel?

> The advantage of this approach is that sysinst can physically modify the 
> real Apple Disk Partition Map and convince the kernel that it has a newly 
> partitioned disk.  The disadvantage of this approach is that the mac68k 
> port still doesn't have native disk labels, although we've existed for a 
> long time without time without them.  THe other disadvantage is that it

I must personally say I think it's fine that we deal with Apple partition
maps in a very Apple-compatable way. :-)
 
Take care,

Bill