On Fri, 20 Dec 2002 10:15:47 -0600 (CST), Scott Garfinkle wrote:
>On Fri, 20 Dec 2002 13:13:09 +0100 (CET), kiewitz wrote:
>> I also want to implement support for 32-bit code.
>Why? Is there anyone who really cares?
So GCONFIG API can get used from PDDs within 32-bit code. This is also needed when
into GCONFIG. It would be also possible that LXAPI uses GCONFIG-API to access PCI bus.
This will be
needed, otherwise we have 2 different enumerations, where in fact one is enough.
Implementing LXAPI into
GCONFIG would allow LXAPI to be available from the start (even for BASEDEVs, because
GCONFIG will get
loaded prior any config.sys BASEDEVs), which is quite nice at least imho and one would
only have to install
one driver at all.
I don't know what you mean by "who really cares". If it's so unimportant, IBM wouldn't
KEE. Also we could just stop our work on ACPI right here and now and forget about OS/2
The API is dynamically extendible, which means one could implement special ACPI
functions that way. Or all
sorts of stuff. My primary concern is currently to generate a generic driver for
device detection & configuration
including hot-plug ability. Leaving the old PCIBUS.snp and ISAPNP.snp in there could
severely mess on
ACPI-only systems. Also SERIAL.snp is halting my notebook on random times and even
this gets fixed by
gconfig, because it will register all PnP devices (including system nodes) to
resource-manager so serial.snp
won't get anything to snoop at. This is also true for ACPI-only systems. I don't want
to know what could halt
My driver is also able to e.g. assign bus-numbers to bridges. This is needed for
cardbus-bridges, because they
don't get assigned on most notebooks by BIOS (even on non-ACPI systems) and some
cardbus drivers assign
a hardcoded bus-number of 2 (!) to the bridge, which means they will at least f**k up
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]