The CGTSTMI macros covers the following functions of slot and token management
outputting a list of the slots in the system
outputting information about a single slot in the system
outputting information about a single token in the system
outputting a list of types of mechanism that are supported by a token
outputting information about a single mechanism that is supported by a token
The C_GetMechanismList and C_GetMechanismInfo functions are performed asynchronously if asynchronous function execution has been specified for the task with C_Initialize.
The functions C_GetSlotList, C_GetSlotInfo and C_GetTokenInfo are always executed synchronously.
A detailed description of the functions of the CGTSTMI macro can be found in PKCS#11 V2.20: Cryptographic Token Interface Standard in section 11.5 “Slot and token management functions” under “C_GetSlotList”, “C_GetSlotInfo”, “C_Get TokenInfo”, “C_GetMechanismList”, “C_GetMechanismInfo”.
Macro | Operands |
CGTSTMI | MF=C / D / L / M / E ,VERSION=001 / 002 ,ACTION=*GETSLOTLIST / *GETSLOTINFO / *GETTOKENINFO / *GETMECHANISMLIST / *GETMECHANISMINFO / <var: enum-of default: _action_set.undefined ,TOKNPRS=<var: int:1> / *TRUE / *FALSE / 0 ,SLOTID=<var: int:4> / <integer 0 .. 2147483647> / 0 ,TYPE=<var: int:4> / <integer 0 .. 2147483647> / 0 ,INFO=<var: pointer> / NULL ,COUNT=<var: int:4> / <integer 0 .. 2147483647> / 0 ,BOID=<var: int:4> / 0 ,RPOSTAD=<var: pointer> / NULL ,RPOSTL=<integer 1..2> / <var: int:4> / 0 |
VERSION
specifies which version of the parameter area is to be generated. It is always advisable to use the latest version.
=001
This generates the format that was supported by CRYPT V1.0. This format only supports the parameters already known in CRYPT V1.0.
VERSION=001 is the default.
=002
This generates the format that is supported as of CRYPT V1.1.
ACTION
Type of action.
The corresponding PKCS#11 function is specified for each action code.
=*GETSLOTLIST
corresponds to the PKCS#11 function C_GetSlotList;
outputs the list of slots in the system.
=*GETSLOTINFO
corresponds to the PKCS#11 function C_GetSlotInfo;
outputs information about a single slot in the system
=*GETTOKENINFO
corresponds to the PKCS#11 function C_GetTokenInfo;
outputs information about a single token in the system
=*GETMECHANISMLIST
corresponds to the PKCS#11 function C_GetMechanismList;
outputs the list of types of mechanism that are supported by a token
=*GETMECHANISMINFO
corresponds to the PKCS#11 function C_GetMechanismInfo;
outputs information about a single mechanism that is supported by a token.
TOKNPRS
Information about the current token;
is only relevant for the action *GETSLOTLIST.
=*TRUE
A token must be available.
=*FALSE
It is not relevant whether a token is available or not.
SLOTID
ID of the slot
TYPE
Mechanism type: value from _mechanism_set (see also section “CPKC11T – generaldata types”);
is only relevant for the action *GETMECHANISMINFO.
INFO
The type of information output depends on the action:
*GETSLOTLIST: NULL_PTR or pointer to a memory location that receives the slot list.
*GETSLOTINFO: INFO points to the memory location that receives the slot information.
*GETTOKENINFO: INFO points to the memory location that receives the token information.
*GETMECHANISMLIST: NULL_PTR or pointer to a memory location that receives the mechanism list.
*GETMECHANISMINFO: INFO points to the memory location that receives the information about the mechanism.
COUNT
The memory size depends on the action:
*GETSLOTLIST:
INFO = NULL_PTR: Returns the number of slots;
INFO <> NULL_PTR: Must contain the size of the memory that INFO is pointing to. The size of the memory corresponds to the number of SLOT_ID elements.*GETSLOTINFO: COUNT is not evaluated.
*GETTOKENINFO: COUNT is not evaluated.
*GETMECHANISMLIST:
INFO = NULL_PTR: Returns the number of slots;
INFO <> NULL_PTR: Must contain the size of the memory that INFO is pointing to. The size of the memory corresponds to the number of MECHANISM_TYPE elements.*GETMECHANISMINFO: COUNT is not evaluated.
BOID
Event identification
in the case of synchronous execution: BOID is not used.
in the case of asynchronous execution: event identification to which the end of function processing is signalled.
RPOSTAD
Postcode address
in the case of synchronous execution: RPOSTAD is not used.
in the case of asynchronous execution: specifies a field containing postcode information which is to be transferred to the corresponding program that issues the SOLSIG call (see also “Executive Macros” user guide [3]).
Length of postcode: 4 or 8 bytes
RPOSTL
Length of postcode
in the case of synchronous execution: RPOSTL is not used.
in the case of asynchronous execution: specifies the length of the postcode information in words (1 or 2).