From owner-freebsd-hackers  Fri Oct 13 11:25:30 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id LAA08302
          for hackers-outgoing; Fri, 13 Oct 1995 11:25:30 -0700
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA08292
          for <hackers@FreeBSD.ORG>; Fri, 13 Oct 1995 11:25:27 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17947; Fri, 13 Oct 1995 11:19:51 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199510131819.LAA17947@phaeton.artisoft.com>
Subject: Re: IPX now available
To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs)
Date: Fri, 13 Oct 1995 11:19:51 -0700 (MST)
Cc: julian@ref.tfs.com, terry@lambert.org, jhay@mikom.csir.co.za,
        hackers@FreeBSD.ORG
In-Reply-To: <199510130612.XAA05319@aslan.cdrom.com> from "Justin T. Gibbs" at Oct 12, 95 11:12:56 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2037      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> Actually, I'd rather not have to have all of the IRQ, DRQ, ports, etc
> determined during probe.  Look at EISA or PCI devices... the probe is
> a non-intrusive determination if a card is present and what driver may
> be apporpriate for that device.  The IRQ, DRQ, and port range determination
> should only happen after we know that we have something worth talking to
> (ie the probe is successfull).  This works so long as we allow attaches
> to fail (which they could for other reasons like insufficient memory).
> I'd rather design the system to look like:
> 
> probe ()
> {
> 	minimum to determin presence of hardware

AND determine the allowable ranges for IRQ/DRQ/IO/memory this device

> }

meta_attach()
{
	create a graph of "least relocatable" to "most relocatable"
	determine desirable "location freeze" for each device
	call per device attach with location information
}

> 
> attach()
> {

> 	Determin port Addresses
> 	if (!reserve port address) {
> 		return some error code
> 	}
> 	Determine IRQ
> 	if (!Map IRQ Handler) {
> 		release port address
> 		return some error code
> 	}
> 	Register other resources...
> 	Setup the card for work
> 	Enable interrupts
> 	return success
> }
> 
> The new EISA code will follow this approach.

As should PCI, PCMCIA, and ISA if mapped using a PCI<->ISA bridge (ie: PCI
is the primary bus, ISA is the secondary).

The caveat on destructive probes (those involving triggering of interrupts,
like IN/Lance ethernet, etc.) is that they must be prevented.

A destructive probe should be limited to a "add hardware mode".  Just like
Windows 95: a user triggered event or an install triggered event that does
not repeat each boot.

A destructive probe system like this may require, in the short term, the
ability to disable the device (per the current mechanism) and in the long
term, the cooperation of the install and hardware administration tools.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.