VMS Help
System Services, $CPU CAPABILITIES (Alpha Only)
*Conan The Librarian (sorry for the slow response - running on an old VAX)
|
|
On Alpha systems, allows modification of the user capability
set for a specified CPU, or for the global user capability CPU
default.
This service accepts 64-bit addresses.
Format
SYS$CPU_CAPABILITIES cpu_id [,select_mask] [,modify_mask]
[,prev_mask] [,flags]
C Prototype
int sys$cpu_capabilities (int cpu_id, struct _generic_64
*select_mask, struct _generic_64
*modify_mask, struct _generic_64
*prev_mask, struct _generic_64
*flags);
cpu_id
OpenVMS usage:longword
type: longword (unsigned)
access: read only
mechanism: by value
Identifier of the CPU whose user capability mask is to be
modified or returned. The cpu_id argument is a longword
containing this number, which is in the supported range of
individual CPUs from 0 to SYI$_MAX_CPUS -1.
Specifying the constant CAP$K_ALL_ACTIVE_CPUS applies the current
modification operation to all CPUs currently in the active set,
and to the default CPU initialization context in SCH$GL_DEFAULT_
CPU_CAP. If the prev_mask argument is also supplied, the previous
default CPU initialization context in SCH$GL_DEFAULT_CPU_CAP will
be returned rather than any specific CPU state.
To modify only the user capabilities in SCH$GL_DEFAULT_CPU_CAP,
the flags argument has a bit constant CAP$M_FLAG_DEFAULT_ONLY.
When this bit is set, all service operations are performed on
the global cell rather than on an individual CPU specified in
the cpu_id argument. This bit does not supersede the CAP$K_
ALL_ACTIVE_CPUS constant, however. If both constants are
specified, CAP$K_ALL_ACTIVE_CPUS take precedence; nevertheless,
the operations to SCH$GL_DEFAULT_CPU are identical because that
function is a direct subset of the other.
select_mask
OpenVMS usage:mask_quadword
type: quadword (unsigned)
access: read only
mechanism: by 32- or 64-bit reference
Mask specifying which bits of the specified CPU's user capability
mask are to be modified. The select_mask argument is the 32-
or 64-bit address of a quadword bit vector wherein a bit, when
set, specifies that the corresponding user capability is to be
modified.
The individual user capability bits in select_mask can be
referenced by their symbolic constant names, CAP$M_USER1 through
CAP$M_USER16. These constants (not zero-relative) specify the
position in the mask quadword that corresponds to the bit
name. Multiple capabilities can be selected by connecting the
appropriate bits with a logical OR operation.
The constant CAP$K_ALL_USER, when specified in the select_mask
argument, selects all user capability bits.
modify_mask
OpenVMS usage:mask_quadword
type: quadword (unsigned)
access: read only
mechanism: by 32- or 64-bit reference
Mask specifying the settings for those capabilities selected in
the select_mask argument. The modify_mask argument is the 32-
or 64-bit address of a quadword bit vector wherein a bit, when
set, specifies that the corresponding user capability is to be
added to the specified CPU; when clear, the corresponding user
capability is to be removed from the specified CPU.
The bit constants CAP$M_USER1 through CAP$M_USER16 can be used
to modify the appropriate bit position in modify_mask. Multiple
capabilities can be modified by connecting the appropriate bits
with OR.
To add a specific user capability to the specified CPU, that
bit position must be set in both select_mask and modify_mask. To
remove a specific user capability from the specified CPU, that
bit position must be set in select_mask and cleared in modify_
mask.
The symbolic constant CAP$K_ALL_USER_ADD, when specified in
modify_mask, indicates that all capabilities specified in select_
mask are to be added to the current user capability set. The
constant CAP$K_ALL_USER_REMOVE indicates that all capabilities
specified are to be cleared from the set.
prev_mask
OpenVMS usage:mask_quadword
type: quadword (unsigned)
access: write only
mechanism: by 32- or 64-bit reference
Previous user capability mask for the specified CPU before
execution of this call to $CPU_CAPABILITIES. The prev_mask
argument is the 32- or 64-bit address of a quadword into which
$CPU_CAPABILITIES writes a quadword bit mask specifying the
previous user capabilities.
If this argument is specified in conjunction with CAP$K_ALL_
ACTIVE_CPUS as the cpu_id selection constant or with CAP$M_
FLAG_DEFAULT_ONLY, the user capability portion of the default
boot initialization state context SCH$GL_DEFAULT_CPU_CAP will be
returned.
flags
OpenVMS usage:mask_quadword
type: quadword (unsigned)
access: read only
mechanism: by 32- or 64-bit reference
Options selected for the user capability modification. The flags
argument is a quadword bit vector wherein a bit corresponds to an
option. Only the bits specified in the following table are used;
the remainder of the quadword bits are reserved and must be 0.
Each option (bit) has a symbolic name, defined by the $CAPDEF
macro. The flags argument is constructed by performing a logical
OR operation using the symbolic names of each desired option.
The following table describes the symbolic name of each option:
Symbolic Name Description
CAP$M_FLAG_DEFAULT_ Indicates that the specified operations
ONLY are to be performed on the global context
cell instead of on a specific CPU.
This bit supersedes any individual CPU
specified in cpu_id but does not override
the all active set behavior (CAP$K_ALL_
ACTIVE_CPUS). Specifying this bit constant
applies this operation to the default
startup capabilities for all CPUs booted
for the first time.
CAP$M_FLAG_CHECK_CPU Determines whether the kernel thread can
be left in a nonrunnable state under
some circumstances. No operation of
this service allows a transition from a
runnable to blocked state; however, if
the kernel thread is already at a blocked
state, this bit determines whether the
result of the operation must leave it
runnable. If CAP$M_FLAG_CHECK_CPU is set
or flags is not specified, the kernel
thread is checked to ensure that it can
safely run on one of the CPUs in the
active set. If CAP$M_FLAG_CHECK_CPU is
not set, any state operations on kernel
threads already in a blocked state are
allowed.
[legal]
[privacy]
[GNU]
[policy]
[netiquette]
[sponsors]
[FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.