Bill Studenmund  (wrstuden@nas.nasa.gov) wrote:

>On Fri, 17 Dec 1999, Bob Nestor wrote:


>> 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).
>
Well if disklabel is capable of loading the new disklabel into the kernel 
without calling a kernel routine to do it I sure couldn't find it!  It 
seems to me that doing this would require access to the kernel symbols so 
it could resolve the address of the incore disklabel. Everyplace I looked 
in disklabel it was issuing an ioctl to do the label manipulation, and 
they always came down into the kernel read/write disklabel routines.

>> 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?
>
Sure, that's exactly what needs to be done.  Now how do you convince the 
kernel that you have a new disklabel and that it should be used instead 
of the one the kernel currently has incore?

>> 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. :-)
> 

That's exactly what I was trying to do here.  Obviously I could have 
moved the Apple Partition Map code into the writedisklabel kernel routine 
and that would have nearly solved the problem of native disk labels.  At 
the time I just wanted to get sysinst working without any kernel changes, 
but I could find no way of convining the kernel to re-read the updated 
disk label.  Pouring thru the disklabel utility lead me down this path.

-bob