> > 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. \\ [EMAIL PROTECTED]
\\ -- Joseph Merrick \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
