[lttng-dev] [CTF] Dynamic enumerations and state system

[Alexandre Montplaisir]

Hi Mathieu,

On 12-01-16 09:16 PM, Mathieu Desnoyers wrote:
> Hi Alexandre,
>
> Recently, I brought forward ideas about adding a new type, "dynamic
> enumeration" to CTF. However, now that I come to think of it, these
> dynamic enumerations would duplicate something that should probably be
> done within the state system. Some information about the kind of
> use-case it covers:
>
> A "dynamic enumeration" could contain the mapping between IRQ handler
> name and IRQ number. This listing is dynamically updated while the trace
> is being recorded.
>
> Adding a dynamic enumeration to CTF would only allow listing "global"
> enumerations that are scoped across the entire OS. However, as soon as
> we'd like to use them for, say, per process enumerations (hypothetical
> example: listing mappings between signal number and the associated
> handler), we cannot use a type as declared within CTF, because it has no
> knowledge of the "per process" scoping in anyway: this is the state
> system's job.

Indeed, we can use sub-attributes to store information about a specific
process, for example something like:

Processes/
  1000/
    IRQ_handlers/
      1
      5
      10

and the state value associated to each attribute /1 /5 and /10 would be
the IRQ name. (Or we could do it the other way around, depending on the
use case).



However, by "dynamic", do you mean you can modify the values after they
have been created? Or only that you can append to the existing enumeration?

If it's the former, then yes the state system is probably the best place
to store that information.

If it's the latter (values don't change after they have been created) we
could still use the state system for that, but it won't be optimal at
the moment. It's on my roadmap to add some kind of "static container" on
the side for state information that does not change throughout a trace
(for stuff like syscall tables and the like). That should be coming up
in the next months.
>
> So my thoughts about this would be to possibly add a dynamic enumeration
> type to the state system, in addition to the value, stack and possibly
> other types it currently supports.

For now it can use integer and string values (the stack type is
basically just a wrapper that uses integer sub-attributes underneath).
It's also possible to use custom "structs" as state values, which can
contain more than one field. But for anything "dynamic" it's probably
easier to just use straight sub-attributes.


-- 
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal