Guidance on snap interface to load a device-tree overlay on RPi Core18


god forbid no ! :slight_smile:

there are cases where you can damage or even completely fry your hardware, no application snap should be allowed to load overlays …

application snaps are not limitable by board, they sit in the store for a specific architecture and while you can namespace them like i.e. “foobar-pi” they will still be installable on any other armhf system … so installing teh foobar-pi (shipping an overlay for the RPi only) snap on some allwinner or imx board will probably set some voltage on some regulator to a value that makes the chip go up in flames … this really needs to be done in the gadget …

that said, the Pi being a special case here with lots of extra hacks like the snap system keys to mangle config.txt via snap set/get, there could surely be a mechanism to set a dtoverlay value from some pi specific interface.


We could have the super-privileged interface but it would strictly be for experimentation only.

If we want first class support for this it would need to be mediated by snapd itself or at least specific gadgets.

I could imagine using the content interface or an interface like it, together with the declaration language that let us control it quite precisely, to provide the DTBs to snapd/the gadget for loading on behalf of the snap but not directly by the snap. In that approach the store/gadget brands and to some extent users but not the snaps would have a voice about what to load.

Is there a way or could a way be conceivable to check for conflict between DTBs before loading them?


@ogra - ok that is a good point re hardware incompatibility etc.

The other option for this is to get the overlay merged into the pi kernel itself, so then only a change is needed to config.txt to specify this to be loaded. This could be mediated and managed by snapd - and if needed down the track perhaps could be extended to allow snaps to ship overlays themselves for snapd to managed as well.

Either way it is probably useful to have this overlay in the standard core 18 pi kernel (since the driver is already there) so I’ll see if I can push that through an upcoming SRU cycle.

Regarding management of overlays via snapd, since we already have various pi config.txt settings accessible via snap set system - perhaps we could just add pi-config.dtoverlay (and may as well then expose dtparam as well -