Hi!
I need to redesign the GCONFIG areas, because of the hotplug support. I'm nearly done
with it, but I also
want to implement support for 32-bit code. This means that the areas will be
accessible via 16-bit ring-0, 16-bit
ring-3 and 32-bit code. Is it possible (or is it done) that PDDs run 32-bit code
during device init (ring-3)?
I mean it is enough to have one linear address? I never wrote a 32-bit PDD, so I don't
know.
I'm currently using the following structure to be CPU mode independant:
Ring-0 selector :word
Ring-3 selector :word
Linear base address:dword
Is this enough?
The current limits of GCONFIG are 8192 concurrent (!) devices. This includes both
fixed and hot-plug
devices. Also the maximum limit of the sub-block area (not needed for all device
types) is around 64MB.
I will also split PCI-Bridges, normal PCI-Devices and cardbus-devices into separate
HWDeviceID groups. PCI
Bridges and PCI-Devices will be accessible via OEMHLP$ PCI functions *and* via GCONFIG
PCI functions.
I'm also looking forward to integrate Linux-API (LXAPI32) into GCONFIG. This would be
possible, also those
functions could use GCONFIG detection area for PCI devices instead of enumerating by
itself. This would
speed up the whole process (and also make it ACPI compatible, as soon as GCONFIG uses
ACPI to know if
PCI is available). Also the LXAPI could get made able to be accessed via FAR CALL
(just like GCONFIG-API).
I don't know if that's already the case.
Cardbus-devices will only be accessible, when the user (or the gconfig daemon) selects
them to be. But this
will also make the physical location of those devices hot-plug unable. This means that
hotplug events wont
get sent out on those physical locations (actually devices won't get recognized on
those positions at all). So
it's relatively safe to use point-enabled drivers. Cardbus devices will be in a
so-called hot-plug group which
means drivers that want to access those, require to have hotplug support and require
to install themselves
into hotplug callback.
Hotplug callback will also work relatively easy from a PDD developers point of view.
Generic events will get
called out during task-time, where as the HWDeviceID and a pointer to the base-block
will be given. This
means that such drivers will get *any* device removal (USB, PCMCIA, Cardbus,
Bluetooth, etc.) via the same
API. They will just check the HWDeviceID group and e.g. check via base-block for
supported VendorID,
device-class, hardware revision or whatever they want. I'm not sure if I should
include a pointer to sub-block
as well, because the base-block already has a pointer. Sub-block contains e.g. device
names, resource
proposals, etc. It does not contain the actual configuration (resource assignments) of
the device, which is
accessible via resource-manager and/or GCONFIG-API. The latter will query run-time, so
the information will
be 100% accurate.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
