From owner-freebsd-hackers Thu Jan 11 05:16:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA17833 for hackers-outgoing; Thu, 11 Jan 1996 05:16:24 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA17808 for ; Thu, 11 Jan 1996 05:16:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA13705; Fri, 12 Jan 1996 00:13:41 +1100 Date: Fri, 12 Jan 1996 00:13:41 +1100 From: Bruce Evans Message-Id: <199601111313.AAA13705@godzilla.zeta.org.au> To: gibbs@freefall.freebsd.org, smpatel@wam.umd.edu Subject: Re: PnP problem... Cc: freebsd-hackers@FreeBSD.org, hasty@rah.star-gate.com, neil@synthcom.com, terry@lambert.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> 1) Disable all PNP devices >>> 2) Probe for ISA >>> 3) Obtain EISA information - report conflicts with ISA devices >>> 4) Initialize EISA devices >>> 5) Init PnP devices >>> 6) Init PCI devices >>> 7) Boot system ;-) This seems about right. >>Unfortuantely, this won't work... In FreeBSD, it goes >But it could. You just need a configuration manager. >>Init PCI >>Init EISA >>Init PC-Card >>Init ISA The current order is: Probe and init PCMCIA Probe and init EISA Probe and init PCI Probe and init ISA and the order in 2.1 was: Probe and init EISA Probe and init ISA Probe and init PCI >The only reason its in that order now is so that PCI/EISA devices that >have an ISA compatibility mode are found by the PCI/EISA probes first. >Neil's approach is more along the lines of how it should be, and the EISA >code at least was written thinking that the attach of devices wouldn't >necessarily follow the probe. Hmm. How do the ISA probes avoid rediscovering PCI/EISA devices? What happens if there is a "bt0 at isa?" (as specified in the config) on the ISA bus and another one on the PCI/EISA bus? I think this doesn't work now. If Neil's approach is used then the corresponding problems are: How does the config manager know that some ISA devices are physically the same as a PCI/EISA device? How does the config manager assign minor numbers in the above complicated case involving bt0 and even in simple cases? >3) Probe all ISA devices. A probe returns whatever information can >be obtained non-invasively. ... That's almost no information. :-( >If a driver can't determine the I/O port, >for example, it returns a map of all possible ports. 0-0x3ff :-). I think ISA probes will have to be just as invasive as now except they will be able to be more careful about clobbering previously probed devices thanks to the more complete resource maps. Bruce