Bill Studenmund wrote:

>Oh, yes, that won't work.
>
Yup, I can confirm that!

>You definitly don't want to do DIOCWDINFO as there's no clean way to go
>from a disklabel structure to what needs to be on disk.
>
The code in sysinst builds the structure that would be required by 
DIOCWDINFO if it worked. Both in my original version of sysinst and in 
the new one that the code segment I provided came from. The problem is 
making sure the in-core label is in sync with the on-disk label. I really 
never liked the idea of writing the Apple Partition Map and then doing my 
own intrepretation of it to build the in-core label.  I preferred having 
some way of getting the kernel to re-process the on-disk label to create 
the in-core label as this bahaviour would be consistent with the next 
boot of the system.  Anyway, hat was part of the problem in the first 
implementation I did. When they got out of sync it was possible to 
over-write non-BSD data on the disk.

>I thought when this last came up, the concensus was to write the on-disk
>label (the apple partition map), and then either load a label into the
>kernel, or have the kernel reload the label off disk.
>
This is basically what I did in sysinst.  It builds a new Apple Partition 
Map and writes it to disk. In my previous version I made a small kernel 
mod to allow the in-core disk partition to be reconstructed from the 
on-disk Apple Partition Map by re-reading and processing the map again.  
This insured the on-disk and in-core were in sync.  But given the 
widespread objects to this I went back and built my own version of the 
in-core label which I attempted to force into use via the ioctl.  That's 
when I discovered the path the kernel code took that basically ignored my 
new in-core label in the very routine I wanted to modify in my earlier 
attempt to get sysinst running. ;-)

>I think re-reading would be the cleanest.
>
Yes!  And the safest.  That way you know the kernel will process the 
on-disk label the same way on the next real boot of the system.  It would 
be horrible if sysinst did it one way during the installation that wasn't 
consistent with the kernel's method.  On the next re-boot of the system, 
right after completing the installation, the kernel would could come up 
with a brain-damamged view of the file system on disk.

>Scott, weren't you going to make a new ioctl to do that?

This was also my understanding that with a new MI approach to the 
disklabel we would have a new ioctl to re-read in the on-disk label into 
the in-core one.  Basically that's the only remaining hold-up for having 
a functional sysinst for the mac68k port.

There is one other minor problem. Sysinst creates new FFS file systems 
which are incompatible with the old Installer and semi-incompatible with 
the current Booter.  It's not a major problem if one never has to go back 
and use the Installer.  The Booter is a slighlty different problem, but 
since sysinst forces the creation of a separate root and usr the root 
tends to be small enough that the Booter almost always succeeds.

-bob