Frederick Bruckman  (fb@enteract.com) wrote:

>On Fri, 17 Dec 1999, Bob Nestor wrote:
>
>> Frederick Bruckman  (fb@enteract.com) wrote:
>> 
>> >This upcoming NetBSD-1.4.2 release will be the first, for mac68k, to
>> >include the new installation kernel as a binary. Look under
>> >"installation/inskernel". Resizing of and creating partitions is known
>> >not to work, but changing partition types, as well as all the MI
>> >functions, should work OK. Try it!
>> 
>> The problem of not being able to resize or create partitions is described 
>> in PR 8434. There's also a patch in there that seems to fix the problem - 
>> on my system at least.  If anyone is adventerous, has the ability to 
>> build their own kernels and wants to try this out I'd appreciate the 
>> feedback.
>
>I confess not to understand. What's the "disklabel -r" for? Doesn't
>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.

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.

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.

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 
is now possible to get the ondisk labels out of synch with the RAM copy 
used by the kernel, but by forcing disklabelwrite to rescan and 
reconstruct the faked incore label we're no worse off than we would be 
with native disk labels if an error occured between writing the lables 
and getting the incore copy updated. If someone were to come up with the 
code to support native disk labels for the mac68k port, it wouldn't cause 
sysinst to break though.  See the comments in the code in sysinst and the 
disklabelwrite routines that are part of PR 8434 to see why.

Although this same approach could be used in "disklabel" to give the 
appearance of native disk labels in the mac68k port, that probably isn't 
a good idea.  The reason is that disklabel is now pretty much MI code and 
runs the same across all ports. Well there is some special code in there 
to deal with the i386 and pmax(?) disk labels on disk, but that code 
isn't as complicated as the sysinst/mac68k code.  Not having any way of 
partitioning the disk is a significant problem especially during a system 
installation which is generally when disklabel is used anyway.  Having 
this code in sysinst right now gets us past that problem and all we're 
left with is an inability to use disklabel to repartition the disk.  
Disklabel still has the ability to read and display the current (or 
updated) disk label though just like always.

The one remaining problem with sysinst seems to be an MI one.  There are 
times that it gets confused about the updated disk label and confuses the 
memory-disk with the physical disk. When this happens the newfs step 
fails and thus the installation fails.  There are other problems with 
sysinst accessing NFS volumes, etc.  These have been reported on a couple 
of other ports and there are PRs outstanding for them.

The other main problem facing us in the mac68k (and macppc) port is the 
lack of a way to access HFS filesystems from the Installation Kernel.  We 
could use hfsutils as we do in an operational kernel, but then they'd 
have to be built into the installation kernel, and that raises some 
questions about licenses.  An Installation Kernel is one monolithic load 
that has with it all the utilities it needs to do it's job. This is not 
the case of an operational kernel which can access external binaries that 
may exist under different licenses.

I hope this explains what is going own with disk labels in NetBSD in 
general and in the mac68k port specifically.  If anyone is interested in 
further information I believe the best way to learn the details is to 
start with the disklabel code and follow the syscalls from there into the 
kernel.  I'd be happy to try to answer questions about the sysinst code 
and how I got it to work without native disk labels if necessary.

-bob