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?