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
--
snappy-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snappy-devel
