4.3 Resources

Resources represent small, named, fixed-sized pieces of state of an instance, for example registers or parameters.

Clients first query a list of all available resources of an instance by calling resource_getList(). Optionally, they can query meta information about all resource groups by calling resource_getListOfResourceGroups(), but calling this function is not necessary to find or access all resources.

Clients can identify resources by:

  • Their name.
  • A canonical register id.
  • Other aspects, for example tags.

Iris registers are always identified by their resourceId, which is an opaque identifier. Resources can be read or written by specifying the resourceId in the functions resource_read() and resource_write(), respectively.

State that consists of smaller chunks that can be addressed and accessed in a uniform way should be represented as memory or a table instead, see 4.4 Memory and 4.6 Tables.

Target instances can expose zero or more resources. Target instances that expose no resources must either return E_function_not_supported_by_instance for all resource_*() functions or must return an empty list for resource_getList(). Each resource has static parts, for example the name and description, and dynamic parts, for example the value.

Parameter and register resources generally behave like normal resources but have extra semantics. For example, parameters can be set at init time. See 4.3.4 Parameters and registers for details.

In summary, the Resources interface provides:

  • A flat list of named resource groups. The name is a short human-readable string, for example GPR or FPU Shadow.
  • A flat list of named resources. Each resource belongs to one or more resource groups.
This section contains the following subsections:
Non-ConfidentialPDF file icon PDF version101196_0100_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.