From owner-freebsd-current  Mon Sep 11 23:32:05 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA24526
          for current-outgoing; Mon, 11 Sep 1995 23:32:05 -0700
Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA24520
          for <current@freebsd.org>; Mon, 11 Sep 1995 23:32:03 -0700
Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id XAA12900; Mon, 11 Sep 1995 23:30:52 -0700
Message-Id: <199509120630.XAA12900@precipice.shockwave.com>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
cc: current@freebsd.org, Bill Fenner <fenner@parc.xerox.com>
Subject: Re: userconfig doesn't work on tvi925 
In-reply-to: Your message of "Mon, 11 Sep 1995 22:45:53 PDT."
             <1535.810884753@time.cdrom.com> 
Date: Mon, 11 Sep 1995 23:30:52 -0700
From: Paul Traina <pst@shockwave.com>
Sender: current-owner@freebsd.org
Precedence: bulk


  From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
  Subject: Re: userconfig doesn't work on tvi925 

  > Here is my suggestion.
  
  It won't work.
  
  > Pull out the new userconfig ENTIRELY.  Get rid of it.  Instead, add a
  > sysctl interface and a staticly linked program in /sbin to operate that
  > interface.  This keeps the kernel clean, and gives you access to fancy
  > stuff in user mode.  If you want to have the old userconfig for
  > emergencies.
  
  Not if you never GET to user mode, it doesn't!  Perhaps by
  complicating the interface we've obscured the purpose somewhat, but
  the primary purpose remains "getting the user installed on the hard
  disk."

Please re-read the last line you quoted...and now let me expand...
  
  What also needs to happen is for `dset' to get folded into sysinstall
  so that the second kernel to come off the bindist can also be tweaked
  to track whatever changes the user had to make in coming up off the
  floppy.

All you need to get to user mode on the install disk is a working floppy
drive and a working console.  It's -highly- unlikely you will need to change
the floppy drive or the location/irq of com1, or the address of your vga
device.  In point of fact, you're ALREADY hosed if those aren't where you
expected them to be, because the boot loader and the console driver that
userconfig() uses wouldn't work in the first place.

QED, you can boot the kernel, get into user mode, and run the fancy program.
If my logic is false, then you STILL have the old dumb-terminal userconfig
program for emergency hardware changes or initial boot without a reboot.