From owner-freebsd-current Tue May 20 09:51:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12799 for current-outgoing; Tue, 20 May 1997 09:51:11 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12770; Tue, 20 May 1997 09:50:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA01485; Tue, 20 May 1997 09:49:13 -0700 From: Terry Lambert Message-Id: <199705201649.JAA01485@phaeton.artisoft.com> Subject: Re: Backwards compatibiliy for isa_driver To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 20 May 1997 09:49:13 -0700 (MST) Cc: se@FreeBSD.ORG, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at May 20, 97 10:43:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't think this needs to be put into every driver, if we > > find a good concept. And that's what I'm after :) > > The problem for ISA devices is that the number of ports used isn't known > until after the probe. The bus can't manage the resources since it > doesn't know how large they are. On the other hand, it's possible to post the ranges (in PnP format) that are allowable probe ranges for the ISA driver in question, as if it were a PnP device. As a result, one can use that information to restrict the probe space, and then use it to map. The trick is to have a flag bit available for each one to determine if that specific area of the probe space should not be tested. This allows for specific static addressing of ISA cards, while maintaining PnP and autoporbe in all other reasonable (non-ISA) cases. Finally, you need a "dummy" device that can be arbitrarily given a set of ports, IRQ's, and address ranges, to allow for unsupported (no driver to claim it) ISA hardware, so that the unsupported hardware does not end up not being seen and the kernel PnP support for non-PnP BIOS machines won't try to locate devices on top of it. Since this is all data, it can be pattern-prefixed and CRC'ed in the kernel data space so as to allow a utility to manipulate the kernel image. This buys yu your "registry" for persistent device information which only operates against devices which need persistent information, instead of screwing all of us. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.