I was mildly annoyed by the fact that a normal kernel didn't
get some devices attached right on a ThinkPad I got between
my fingers. (The first serial line -the infrared one- used irq4
but should use irq10, and the soundblaster compatible audio
didn't find the right dma channels.
So I've put aside my aversions to BIOSes and looked how to get
some information out of it.
For now, the "Plug and Play BIOS" seems to be the preferrable
source of these these data. ACPI seems to be the method of the
future, but for now not even IBM trusts its own implementation.

PnP BIOS calls return basically a list of "device nodes", each
consisting of a "PnP ID" (EISA encoded) and a set of ressources
allocated - quite similar to ISAPnP.
The data are not always complete as I found, and there are obvious
inconsistencies, but the information was usable for the "real"
devices as far as I have tested.

So what could the PnPBIOS buy us?
1. We could make a new first-level bus "pnpbios0 at mainbus0"
  and attach various devices to it. More or less like "ofisa" does.
2. We could register various ressources as used, even if we don't
  have a driver for it, and increase the likelyhood that eg the
  PCMCIA code gets the right interrupts. (At least on the ThinkPad,
  the PCMCIA adapter doesn't have a device node, probably because
  it is a CardBus in reality. After the serial lines were attached
  to "pnpbios", irq4 was free however, which was needed for the
  PCMCIA controller, and things worked.)

What do you think - is this the way to go?

What I have now is the assembler stuff to call the PnP BIOS
(It wasn't possible with the existing "bioscall" code), and
a first cut on a "pnpbios" pseudo-bus with "com" and "sb"
attachments. It works well on the 3 machines I tested on.
I don't have time to complete it right now (I'll be completely
away next week), but it could be built up step by step.

best regards
Matthias