Hi!
I want to discuss the design of FindDevice/FindClass APIs.
I have to options. First use a zero-based index to get multiple matches e.g.
FindDevice (0x1000, -1, FIND_STRAIGHT, 0) would get the 1st device
FindDevice (0x1000, -1, FIND_STRAIGHT, 1) would get the 2nd device and so on.
Or via LastMatch HWDeviceID which would give a slight performance increase, because i
could directly
match the HWDeviceID first (this would also work via internal cache) and then search
from that position w/o
going through all Base-Block-Area-Segments e.g.
HWDeviceID = FindDevice(0x1000, -1, FIND_STRAIGHT, 0) would get the 1st device
NextHWDeviceID = FindDevice(0x1000, -1, FIND_STRAIGHT, HWDeviceID) would get the 2nd.
What do you think?
I also think that the Base-Block access APIs (for searches described by Dani) should
copy out the
Base-Blocks to a caller supplied buffer. This needs to get done imho, because the
device could get detached
and the Base-Block could get overwritten with a different one, so a pointer wouldn't
work. The base-block is
only 64bytes, so this should be fine. The other option would be to offer 2 separate
APIs. One that would only
allow access to fixed HWDevices and giving back a pointer. The other one for hotplug
devices that would
copy over. Also one could remove hotplug device support for this, because the
attachment messages already
contain a pointer to the base-block (which is okay, because the pointer is true at
least till hotplug notification
is done, even if the hotplug device gets unplugged during that notification).
Getting the full detection area from Ring-3 (application!) will get somewhat tricky.
The current method is
opening gconfig$ and reading till EOF. Now, that the detection area is not linear
anymore, I will have to
transfer single base-blocks only and remember the last Base-Block position (aka
Base-Block Index) that got
read out, so if a device detach occurs during read-out, the data won't get mangled up.
The read-out
detection area will be linear again that way and built up like the original one.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
