From owner-freebsd-current Sat Sep 4 19:18:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles519.castles.com [208.214.165.83]) by hub.freebsd.org (Postfix) with ESMTP id 25F3F14EB5 for ; Sat, 4 Sep 1999 19:17:48 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id TAA08633; Sat, 4 Sep 1999 19:10:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199909050210.TAA08633@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Rabson Cc: Peter Wemm , John-Mark Gurney , "Zach N. Heilig" , freebsd-current@freebsd.org Subject: Re: PNP ids missing in sio.c In-reply-to: Your message of "Sun, 05 Sep 1999 00:15:20 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Sep 1999 19:10:44 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'm curious what can be made of the PNP resource list we get from the BIOS > > at boot time... It lists motherboard resources too, we could probably end > > up with a fairly complete map of known resources to avoid. > > I bet we can roll another enumerator similar to pnp.c which takes the bios > output and turns it into devices. It would mean removing all the probe > hints from your kernel config to avoid confusion but apart from that it > should work really well. This is one reason why I think that the PnP scan should be done _before_ the legacy scan; there are cases where the legacy scan is going to find stuff that the PnP enumerator also knows about. If the PnP enumerator has already found it, then the legacy scan aborts; in the reverse situation the PnP enumerator has no way of knowing that the device has already been claimed. As for the BIOS PnP info; all I'm doing at the moment is scanning for device and compat IDs. Since the information is formatted in exactly the same fashion as ISA PnP data, I was hoping to actually dump the current pointless scan and hook the BIOS access method into the new PnP code. Another argument for making the PnP scan first is that the BIOS identifies a whole pile of "do not go there" regions which you don't want anything, even a legacy device probe, looking at. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message