> Right, but you still have to ask I2O for the same info that you used to 
> ask the BIOS or figured out for yourself.  The device info has to come 
> from *somewhere*, yes?

Of course. I was trying to point out the advantage of a better-documented
source for that device info. Maybe I2O was a bad example since it is very
hostile towards free source groups.

> Mostly.  Probing ISA devices is the worst of it.  Probing PCI devices 
> shouldn't take any time, but probing for SCSI devices does.  Then 
> there's all that broken/crappy hardware that you have to work around in 
> some fashion or other.

Okay, sounds like I want to experiment with extremely nailed kernel configs.

Hmm, what does everyone think of schemes to delay the time-consuming things
like SCSI probing? For instance, suppose I have a "speculatively" nailed
SCSI bus (using the SunOS GENERIC scsibus0 as inspiration):

    sd0 at scsibus0 targ 3
    sd1 at scsibus0 targ 1
    sd2 at scsibus0 targ 2
    sd3 at scsibus0 targ 0
    st0 at scsibus0 targ 4
    st1 at scsibus0 targ 5
    sr0 at scsibus0 targ 6

Then, assuming scsibus0 is succesfully probed at bootup, there is no need
to actually probe each SCSI device until the first time one of its device
nodes is accessed.

Gee, I'm really bending over backwards trying to find ways to make my
kernel boot faster. It just irks me that O/S initialization time still
depends on what might as well be an egg timer (which has measured 3
minutes since the dawn of time) instead of the CPU clock speed (which
grows exponentially over time).

Todd Whitesel
toddpw @ best.com