From owner-freebsd-hackers Fri Oct 13 15:14:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA14817 for hackers-outgoing; Fri, 13 Oct 1995 15:14:59 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA14811 for ; Fri, 13 Oct 1995 15:14:56 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA31165; Fri, 13 Oct 1995 15:07:54 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA04477; Fri, 13 Oct 1995 18:07:52 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id SAA24191; Fri, 13 Oct 1995 18:16:36 GMT Message-Id: <199510131816.SAA24191@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Terry Lambert Cc: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Fri, 13 Oct 1995 11:19:51 MST." <199510131819.LAA17947@phaeton.artisoft.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 13 Oct 1995 18:16:36 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk In <199510131819.LAA17947@phaeton.artisoft.com>, Terry Lambert wrote: > > 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 Agreed. The probe routine should allocate no resources (such as VM) and no local state (ie. no private information for the driver's attach routines). It only provides information to configuration manager about the number of devices, and the ranges for the device. Note that for IRQ that not only the values should be supplied, but the types of IRQ that are supported (level, edge) as well. Either via a smarter bootloader or a VM86 mode, calls into the BIOS to get configuration information should be done as well. For instance, getting the information out of the EISA CMOS should the DEPCA driver since the DE422 config registers are write-only. Also, the probe needs to be done once on a per bus-type basis; a probe should never try to all the different bus types at once. For PCI, I'm beginning in favor of having the driver call a pci_match routine to find instances of itself instead of the currently "passive" method. The passive method just doesn't lend itself to LKM. One other reason I favor it is so that I could have a "generic" DC21x4X module and then have various board/chip specific LKMs. The de driver is getting fairly large and I'd like a method to trim out the unneeded code. > > } > > 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 On the pci-sig mailing list, it seems many BIOS makers are putting in a Micro$oft configuration mode which only configurations "boot" devices and then expects the PnP O/S to call into the PCI BIOS to finish configuring all the other devices. For PnP devices that need configuring, the meta_attach is responsible for setting them to the proper drq/irq/port/memory/etc. > } > > > > > attach() > > { At this point in time, the configuration manager should have assigned (either dynamically if needed or statically if required) the port address, IRQ, and memory (and any other bus-specific resources). The driver should not have to pick anything at this point. > > Determin port Addresses At this point, the only the driver can do is either verify that the device exists at this address and is setup correctly. > > if (!reserve port address) { > > return some error code > > } > > Determine IRQ > > if (!Map IRQ Handler) { > > release port address Only if said port address was dynamically assigned to the device, if the port (or memory) address is fixed then that address should not be released. Note that if there was a conflict, the configuration manager should have never bothered to call the attach routine. > > 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. In my mind, if a user configures a device (such the probe and/or meta_attach is bypassed) and then the attach routine is called, the attach is allowed to do the equivalent of a destructive probe since it unconditionally owns those resources. ---- The database created by the configuration manager and filled in by the probes and refined by the meta_attaches must be non-volatile and independent of the kernel. Note that this means that either the resource information in the config file disappears or config will need to able to write out a resource database file. The boot loader will need to able to read this configuration database and put it into memory along side the kernel image. Userconfig could then either stay in the kernel or become a separate entity. Actually, it might even make sense for userconfig to become the second-stage loader since it will have the proper information to do it. Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message