Aros/Developer/Docs/HIDD/PCI
Introduction[edit | edit source]
Our official API for dealing with PCI is through set of HIDD classes. Prometheus.library is just a wrapper on top of these HIDDs. prometheus.library is not a higher level api, it offers just a subset of what PCI classes can give. The only thing PCI classes are missing are the AddIntServer() and RemIntServer() methods.
You can ask PCI subsystem for available devices and then, for each of them, use the methods of PCIDevice object. THe PCIDevice object itself may be internally bound to any currently active PCIDriver in the system. Yes, there can be more than one PCIDriver in use at the same time.
so it is an opaque driver component to external code.
The PCI HIDD on the other hand only has one method useful to external code: EnumDevices. It is on the purpose. The code is supposed to use PCIDevice objects.
Ask PCI subsystem for available devices and then, for each of them, use the methods of PCIDevice object. The PCIDevice object itself may be internally bound to any currently active PCIDriver in the system. Yes, there can be more than one PCIDriver in use at the same time.
Don't memory-related operations have to be done through PCIDriver objects., e.g. the AllocPCIMem method? There is no problem by adding these methods to PCIDevice class. Since PCIDevice object knows exactly which drivers handles it, it could delegate the methods to corresponding driver with ease.
Have a read of the Aros-Exec thread.
To me, prometheus.library is to the PCI HIDD what (cyber)graphics.library is to the graphics HIDD(s). For instance, we don't encourage applications to call the graphics HIDD directly AFAIK.
or:
PCI.hidd represents a subsystem the same way as graphics.library is representing a system. graphics.hidd is a driver component in graphics.library subsystem, same as PCI-DRIVER.hidd is a driver component in PCI.hidd. But the PCI-DRIVER HIDD has to be used when accessing the PCI subsystem, so it is not an opaque driver component to external code. The PCI HIDD on the other hand only has one method useful to external code: EnumDevices. Therefore do not see true symmetry in your comparison.
Before the PCI subsystem for AROS there were other solutions studied and none of them was satisfactory. In particular openpci used copy&pasted linux headers. Not to mention that in those days, the openpci was hardly used.
- AmigaOS 3.x uses prometheus, openpci and others
- Amithlon uses different library to access pci devices, quite similar to the openpci, but still not the same
- MorphOS uses pcix.library and provides openpci wrapper for it
- AmigaOS 4.x uses PCI interface of expansion library
- AROS uses oop-based PCI classes
Compared to rest of the list AROS is not the only one, which is "different" than others. Actually, there is *no* really cross-platform solution for accessing PCI devices available for all amiga platforms. Many AmigaOS drivers use prometheus, few of them use openpci. OS4 components use the PCI interface of expansion.library, MOS drivers use pcix.library (some of them which are not provided by the MOS team will probably use openpci).