From owner-freebsd-hackers  Tue Jan  2 21:02:21 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA10046
          for hackers-outgoing; Tue, 2 Jan 1996 21:02:21 -0800 (PST)
Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA10033
          for <freebsd-hackers@freebsd.org>; Tue, 2 Jan 1996 21:02:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by chrome.jdl.com (8.6.12/8.6.12) with SMTP id XAA02277; Tue, 2 Jan 1996 23:03:06 -0600
Message-Id: <199601030503.XAA02277@chrome.jdl.com>
X-Authentication-Warning: chrome.jdl.com: Host localhost didn't use HELO protocol
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
cc: obrien@cs.ucdavis.edu (David E. O'Brien),
        freebsd-hackers@freebsd.org (FreeBSD Hacker's list)
Subject: Re: X for install 
In-reply-to: Your message of "Tue, 02 Jan 1996 17:42:54 PST."
             <1164.820633374@time.cdrom.com> 
Clarity-Index: null
Threat-Level: none
Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code.
Net-thought: If you meet the Buddha on the net, put him in your Kill file.
Date: Tue, 02 Jan 1996 23:02:46 -0600
From: Jon Loeliger <jdl@jdl.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

Apparently, "Jordan K. Hubbard" scribbled:
> It found
> my NIC and popped a configuration screen for it in my face, then it
> found my NCR and the CDROM attached, finished its basic installation
> then detected my Matrox and offered me a screen setup dialog.  System
> [...]
> That's how it *should* work, and as far as I can see, much of the
> "magic" comes from a little utility named `NTDETECT' - It apparently
> figures out who's where and reports this information back to higher
> level code which can say "Aha!  A Forchknacker EMT5023 NIC!

> I've often stated my willingness to do the "GUI" grot that would be
> required to make all those nifty auto-configuration screens come up,
> but the `NTDETECT' side of things is not really in my area of
> expertise.  Knowing how to stomp around in the PC memory & I/O address
> spaces and deal (hopefully) robustly with errors and cards going wiggy
> when probed is a black art.  Any black magicians out there interested
> in starting a `FreeBSD Detect 1.0' project? :-)

This sounds to me like the same general goal as the separation of
the hardware detection process during boot -- part of the detect,
semi-probe, negotiate, allocate, attach process that we've often
discussed.  Can the same core be used for both the normal UNIX boot
process and for the initial system config/install process?  Or am
I totally in the weeds here?

jdl