Enable trace tools as part of the meta-elisa build

[pahmann]

In order to trace the workload of the instrument cluster work group and to benefit from the work in the medical devices working group, we need to enable the specific yocto layers for the tools mentioned in https://github.com/elisa-tech/ELISA-White-Papers/blob/master/Processes/Discovering_Linux_kernel_subsystems_used_by_a_workload.md

On target installation for raspbian (openAPS) is done with the following packages:

• Install tools to build Linux kernel and tools in kernel repo.

  sudo apt-get build-essentials flex bison yacc
  
  sudo apt install libelf-dev systemtap-sdt-dev libaudit-dev libslang2-dev libperl-dev libdw-dev 

• Browsing kernel sources

  sudo apt-get install cscope

• Install stress-ng

  apt-get install stress-ng

• Install paxtest

  apt-get install paxtest

• Tools

  • strace
  • cscope
  • perf
  • stress-ng
  • paxtest

[sudipm-mukherjee]

@pahmann I am not sure why you will want to have cscope and paxtest in the image.

cscope is a tool to browse the source code, and we do not have any source code to browse in the generated image. https://cscope.sourceforge.net/ mentions Cscope is a developer's tool for browsing source code

paxtest is a "Test suite for the PaX kernel patch". which afaik, will be enabled when the kernel config GCC_PLUGIN_STRUCTLEAK and kernel hardening features are enabled. But AGL kernel that we use does not enable these configurations. So, paxtest without these kernel features will not mean anything in our image.

[pahmann]

@sudipm-mukherjee good point. Paxtest was used to create a workload to be traced. This exemplary example will not be needed for our activities. Reading the whitepaper also stress-ng was used to basically trace the workload generated by it. Running stress-ng on the image I judge still as a useful extension, even, if not suitable for tracing our workload (maybe more for interference argumentation). It seems from the tracing tool, cscope is used to browse and find matching kernel symbols. I assume, we can use it also on the host system to figure out, which calls are pointing to which source code elements. My understanding is, that we will trace workloads and see which parts of the kernel are triggered, but as it is not plain text, we can use cscope to figure out which part of the kernel to be analysed further. Summary:

• no need for paxtest
• no need for cscope (maybe on host system)
• stress-ng not for the direct scope, but a good first extension for testing in general.