On Tue, 31 Dec 2002 19:01:28 +0100 (CET), Daniela Engert wrote:
>>Also because most GCONFIG internals are pure assembly, a flat-selector could make
>things worse. If I
mistype
>>something now and a bad offset is used somewhere, it will result in either corrupted
>area/data-segment or
>>exception. By using a flat ring-0 selector, I may accidentaly corrupt some other
>data, also I wouldn't be able
to
>>use e.g. carry flag on 64k overflow trick. Instead I would have to use compares and
>an additional register
(a
>>shame in search routines).
>I'm really looking forward into how you are going to marry this with
>the all flat 32bit ACPI stuff.
Hmm, enumeration under GCONFIG is currently done by 100% 16-bit PM (PnP, PCI).
Each pointer in the configuration area is actually a triple-pointer, which means 2
selectors and one linear
address. I thought that I would only have to generate/destroy HWDevices under 16-bit
PM, but if it's required
modification from 32-bit PM would also be possible. The structures are designed to be
accessible from
anywhere.
I don't know how configuration on ACPI works in the whole. If it needs 32-bit PM (BIOS
calls?) for e.g.
detection, thunking is the only way.
At least the binary PnP information format has remained the same. I will just need to
get an ACPI pointer (and
that's afaik physical memory pointer) to the buffer instead of using PnP isolation
and/or PnP BIOS System
nodes, so 16-bit PM should work at least for ACPI PnP enumeration.
Are PnP devices (non system node) handled the "normal" way (PnP isolation procedure)
or are they detected
by ACPI and analysed by the BIOS instead? In any case, my current (parsing) routines
should work and just
little tweaking will be needed.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
