Date: Fri, 13 Oct 1995 11:19:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs) Cc: julian@ref.tfs.com, terry@lambert.org, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG Subject: Re: IPX now available Message-ID: <199510131819.LAA17947@phaeton.artisoft.com> In-Reply-To: <199510130612.XAA05319@aslan.cdrom.com> from "Justin T. Gibbs" at Oct 12, 95 11:12:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510131819.LAA17947>