Frederick Bruckman  (fb@enteract.com) wrote:

>On Mon, 20 Dec 1999, Bob Nestor wrote:
>
>> Bill Studenmund  (wrstuden@nas.nasa.gov) wrote:
>> 
>> >Check out DIOCSDLABEL, which just modifies the in-core label. You pass it
>> >a struct disklabel *, and it loads that. In fact, most disk drivers have
>> >DIOCSDLABEL and DIOCWDLABEL using the same code path except right at the
>> >end where DIOCWDLABEL writes it to disk too.
>> 
>> This is a simple change to the sysinst code if you'd like to make it, or 
>> if you'd prefer I can do it and test it for you.
>
>That sounds like the ticket. You can't break something that's broke
>already. (I mean sysinstall, rather than the disklabel code.)
>
>It sounds like sysinstall is your baby, but if you're not proficient
>with cvs yet, let's do this:  give me a patch against current, I'll
>test it against 1-4, and if it works, I can commit it (with your name
>on it) and request a pull-up.
>
OK.  I've got a -current source tree and I'll work on it tonite.  I'll 
send you the patches when I have it running.  Commit them with your name; 
I'd rather have some company on supporting this puppy.  I assume you want 
the changes to the INSTALL documentation too?  They need to be reworked 
to fit into the current version of the sources, but other than that they 
are still valid - assuming there's no objection to the way I described 
the INSTALL process with sysinst.

>> Or maybe you'd rather wait for the long-term fix that implements
>> the ioctl to re-read the disk label.
>
>FWIW, it sounds good to me, but Scott will have to fight for that
>himself in the appropriate forum.
>
Agreed.  It's over my head. I personally perfer to cause confusion in 
only one port at a time.

>I've decided to request pull-ups for all the changes I made to current
>to make the install kernel build automatically with "make release".
>This is going to take some preparation, because they're all spread
>out, and some need to be patched by hand, but I think it's worth it.
>
>On your problem building the notes in current, this is evidently due
>to fallout from changes to the nroff macros in current. Those are just
>warnings, right? The install kernel make still succeeds?

No, there are a number of problems building with -current source.  A 
"make all" at the top level fails with some problems in building libc.  
Building an Installation Kernel fails with an error in x_ftp, and past 
that the final merge step fails because of an unresolved reference to 
softdep code in the INSTALL kernel.  The nroff problems were just 
warnings and didn't stop the build, but they should be fixed I think. The 
build of the miniroot also bombed, but I never did get that to work even 
back in the 1.4 source when I first worke don sysinst.

-bob