The following is partly a cutup of Windows 95 ('Final Beta'), and partly notes
about how NOT to do things for NetBSD. (Odd that those two go together hmm ;-)

> [Quoting Terry Lambert:]
> 
 [...] 
> In Windows 95, both the concept of hot plugging and the concept of
> one time destructive probing are covered.  During the install, each
> possible device for which a destructive probe exists is scanned for,
> with logging of the entry and exit of states, and a save of the fact
> that the process has started.

Except of course that doing a proper state save before starting the destructive
scans would save a huge amount of time in the case that a destructive probe
succeeds. Win95's install claims it will remember what it was doing and
continue when you rerun the install (after powering down), but it goes through
a long process of searching the hard drive (and doing other things) after 
each boot, before continuing the probing.

One goal for NetBSD should of course be to attempt to make the install take
as short a period as possible. Since installation is the first look that a
user gets at a new system, smooth and fast are good first impressions to leave.

> What they do is do the major work of probing as part of the install
> process, with a note to the user that that is what they are doing,
> a "percent complete" indicator bar, and a statement to the effect
> that "if this takes too long, reset your machine".

I call this the 'I'm now going to do everything I can to crash your machine'
phase.

Note that for all 6 of my 'crashes' the mouse continued to operate, which 
indicates to me that the CPU hasn't hung itself. Having another TSR/VXD
to monitor the testing could make the whole process much smoother.

I can see many Windows users I know calling me after a day or so to ask
'Has it taken too long now?'

> If a reset is called for because of a destructive probe, then the
> software knows what has and hasn't probed prior to that point, and
> it can skip the failing probe and go onto the next item.

I cannot think of a case where a destructive probe is a requirement rather 
than an option. That is, for any given device, I believe there is a method
to do a non-destructive probe to locate it. It's simply a matter of creating
a matrix of tests and reordering them so that any possibly destructive test
comes after a test to see whether the later test would be destructive or not.

> By doing the destructive probes at the start, the kernel can be much
> less generic and much more statically configured (using a data-driven
> mechanism to cause the loading and configuration of particular drivers),
> with a great advantage in startup time.

Yes, this is true, and improves stability, but it also means loosing some of
the features of automatically detecting devices at bootup - since at the 
moment we can reconfigure our hardware at whim.

My system needed restarting 6 times to complete W95 installation. It took an 
hour and a half, and that's installing from CD - floppy swapping would have
driven me nuts and taken a lot longer too. To top it off W95 didn't install
a CD-Rom driver, even though I had selected it, which left me with the 
catch-22 of how to install the Cd-Rom driver from the Cd which I couldn't read.

My point is simply that I find W95 to have a sloppy installation process, 
which doesn't look very well thought out. NetBSD can do _much_ better, and
provide a more welcome introduction to a new OS. 

							David Maxwell
							david@web.net