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

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> 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.

It's the former.

> 
> 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.

Good to hear that the state tree is a good container for this kind of
information. So I'll drop the "dynamic enumerations" from my CTF
roadmap.

Thanks,

Mathieu

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

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com