|CSX_DUPHANDLE(9F)||Kernel Functions for Drivers||CSX_DUPHANDLE(9F)|
#include <sys/pccard.h> int32_t csx_DupHandle(acc_handle_t handle1, acc_handle_t *handle2, uint32_t flags);
Both handles must be explicitly freed when they are no longer necessary.
The flags argument is bit-mapped. The following bits are defined:
WIN_ACC_NEVER_SWAP Host endian byte ordering WIN_ACC_BIG_ENDIAN Big endian byte ordering WIN_ACC_LITTLE_ENDIAN Little endian byte ordering WIN_ACC_STRICT_ORDER Program ordering references WIN_ACC_UNORDERED_OK May re-order references WIN_ACC_MERGING_OK Merge stores to consecutive locations WIN_ACC_LOADCACHING_OK May cache load operations WIN_ACC_STORECACHING_OK May cache store operations
WIN_ACC_BIG_ENDIAN and WIN_ACC_LITTLE_ENDIAN describe the endian characteristics of the device as big endian or little endian, respectively. Even though most of the devices will have the same endian characteristics as their busses, there are examples of devices with an I/O processor that has opposite endian characteristics of the busses. When WIN_ACC_BIG_ENDIAN or WIN_ACC_LITTLE_ENDIAN is set, byte swapping will automatically be performed by the system if the host machine and the device data formats have opposite endian characteristics. The implementation may take advantage of hardware platform byte swapping capabilities. When WIN_ACC_NEVER_SWAP is specified, byte swapping will not be invoked in the data access functions. The ability to specify the order in which the CPU will reference data is provided by the following flags bits. Only one of the following bits may be specified:
These values are advisory, not mandatory. For example, data can be ordered without being merged or cached, even though a driver requests unordered, merged and cached together.
PC Card 95 Standard, PCMCIA/JEIDA
|July 19, 1996||OmniOS|