Porting hardware testing tool to snappy Ubuntu core

[Zygmunt Krynicki]

Hi

I'm working on porting a hardware testing tool to snappy. I've done some 
research by looking at the available documentation on the wiki as well 
as by experimenting with a beagle bone black, running 2015-04-23 image.

On classic distributions we rely on a number of third party tools and 
relatively unconstrained access to the system. In snappy we will likely 
have issues related to not having certain tools in the base image and by 
the enforced container / seccomp / apparmor restrictions.

The application is composed of a large number of executables with 
various dependencies (on language runtimes and external commands). Many 
of those run as root to perform some operation.

I did a quick analysis to see what kind of issues we currently face. I 
would love to see how to proceed on each of those, given your plans for 
snappy and best gut feeling on what to.

storage:
- no udisks command line tools
- no udisks service

audio:
- no pulseaudio
- no alsa tools

device enumeration:
- constrained udev (doesn't know about any device)
- no access to /sys
- no access to /dev

display:
- no X (e.g. no way to enumerate supported resolutions, screen 
rotations, monitors, no way to do any changes)
- no mir (ditt, though this is expected at this stage)

time:
  - no access to /sys (for rtc)

cpu:
  - no access to /sys
  - (odd) /proc is fully available, will that change later?

software:
  - (odd) dpkg is still available, will that change later?
  - no api (now) for snappy (should we parse output of "snappy list"?)

power management:
  - no access to /sys
  - should we use systemd APIs?

In exploring this I considered making the whole snappy application 
unconstrained, making it a framework (and letting individual tests be 
snappy applications that use it).

One thing that does stand out as problematic, apart from security 
constraints, is the relative emptiness of the core snappy image.

I think it's unreasonable for us to ship udisks so that we can have some 
simple disk enumeration and storage tests. On the other hand, udisks is 
a well-established "plumbing layer" software that we rely on and would 
not like to have to re-write everything again so that we can work on 
Snappy. I'm sure there's a better way to do it.

Lastly there's the question of language runtimes. I talked to ogra on 
IRC earlier today and he confirmed that all language runtimes will be 
removed down the line. Should we start exploring making each runtime 
that we use and rely on a framework?

Best regards
ZK