rvb@sicily.odyssey.cs.cmu.edu writes:
> The problem being solved is "pcmcia problems" that mean that you can
> not load the distribution and build your specialized kernel.

I don't agree with this statement.  If you are able to boot from a
floppy diskette, why can you not install from it?  Is the real problem
that the floppy drive is not properly supported once NetBSD is booted?
I is a "nice feature" to be able to load the distribution sets off the
network, via a PCMCIA card, but is it the *only* way to install?
Perhaps a good interim i386 solution would be for someone to build
specific boot kernel/install floppies for these troublesome machines.

In my case, the 'ep' driver doesn't work correctly with the 3c905 chipset
on my docking station.  Therefore a GENERIC kernel panics on my
machine if it is in the docking station.  I do not see how a sysctl
would be the appropriate solution to disabling the 'ep* at pci ? ...'
But...  a "general solution" (magic phrase) would allow both problems
to be fixed.  I could easily not attach a device that I know is 
troublesome, and those with broken laptops could tell the PCIC what
interrupts to use.

It wouldn't be necessary to build a complicated UI onto a "config"
feature.  Simply having commands to enable/disable/add devices
would be enough.  :-)  (easily said)

boot -c

config> disable ep* at pci? dev ? function ?
ok
config> add ep0 at pci? dev 1 function 0
ok
config> boot
.....


However these commands would update 'cfdata' and the other locator
data structures is beyond my simple ability, but seems like a SMOP for
someone that understands config and how the locators would need to
be stored for dynamic updates.  I could imagine a simple flag in
'cfdata' meaning something like:
	0	= device disabled
	1	= device enabled
	2	= device enabled, but ask about each instance

Rather than building a config(8?) equivalent into the kernel, perhaps
each device attach routine could check the flag, and call a local
'ask' function if necessary.  Then only devices that have 'ask' functions
can be dynamically configured.  This might prevent the average joe
from shooting himself in the foot.  Also, I would think a routine
local to a device driver is more likely to stay in sync with the devices
actual configuration values. 

Anyway, just some ideas.

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | This space left blank
gillham@whirlpool.com                     | inadvertently.
I speak for myself, not for my employer.  | Contact the publisher.