Porting hardware testing tool to snappy Ubuntu core

Sergio Schvezov sergio.schvezov at canonical.com
Tue Jun 2 13:04:41 UTC 2015

On Tue, Jun 02, 2015 at 02:52:42PM +0200, Zygmunt Krynicki wrote:
> 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

This is fine, it could be provided as some sort of framework if you

> audio:
> - no pulseaudio
> - no alsa tools

This is fine as well.

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

This is per design.

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

Per design. mir will be a framework eventually (look at mterry's

deb2snap example for mir)
> time:
>  - no access to /sys (for rtc)

Debatable, but not entirely blocked due to being able to right your own
apparmor rules.

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

I leave this to jdstrand.
> software:
>  - (odd) dpkg is still available, will that change later?

Pending removal.

>  - no api (now) for snappy (should we parse output of "snappy list"?)

There's a go API, there's going to be a restful interface.

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

No comment on my side.

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

This is a possibility. Or just unconstrain it enough so your tests can

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

We are planning on removing more.

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

Look at deb2snap maybe it solves your problem.

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

snapcraft should be pluggable and take care of language runtimes, but
yes, python3 is going away eventually (as soon as we transition away
from the python dependant components).


More information about the snappy-devel mailing list