The requested interfaces sound reasonable to me for the use case, but they grant quite a lot of privileges. Could you please confirm whether this is a official beagleboard project rather than a personal one?
This is official BeagleBoard project, and once all the kinks are ironed out (and it proves reasonably useful as a package), it will probably be moved to a org account.
In that case I’m happy to support this request. +1 from me for granting bb-imager auto-connection to hardware-observe, mount-observe, udisks2, serial-port and hidraw (#voteFor)
What serial-port slot is this plug connecting in your setup? Could you please share what errors / denials you find when disconnecting the serial-port interface?
I think similar concerns may apply to i2c and hidraw interfaces
The tool could probably show a popup or some such when detecting it runs from a snap and point the user to the documentation telling them how to enable usb hotplug for serial connections …
(and yes, i2c and hidraw won’t work without a gadget snap providing the slot side)
I did test serial-port. And it does work after enabling hotplug. In case of i2c, I was under the impression that it will work in case of static i2c devices (Eg pins on BeagleBoard.org board).
I have special popups planned for both Flatpak and Snaps.
hidraw is very rarely used. So I was considering just marking it as broken until snap gets hotplug for hidraw support in future. It’s just not essential enough functionality to switch to classic confinement.
@ogra@jslarraz Should I just switch to classic if that is preferable. While hidraw can be ignored as non-essential at the moment, that can change in future, so if there is no real plans for hotplug in hidraw, it would be better to just use classic.
It is way harder to package classic (your tools must all be included, your snap must be capable to run on any OS you install it on without relying on external tools and you need to make very sure to keep the environments apart (you are still running in a sandbox, but it is open so leakage from inside to the outside and vice versa can happen easily))
I also highly doubt we have an approved category for tools like this (which is a hard requirement to even get your snap reviewed for classic at all), so the chances you might get it granted are pretty low under the current restrictions (indeed an architect could override this but we have this case very rarely, I’ll leave the judgement to the reviewers here)
As @ogra said, getting classic confinement is not going to be easy as it does not clearly fit in any supported category. I would strongly recommend sticking to strict confinement and re discuss it if/when hidraw becomes essential.
Ok, I will stick to strict confinement for now. Since the only usecase of hidraw at the moment requires hotplug support (basically over usb), I don’t need auto-connection for it.
However, auto-connection for i2c can still be used in embedded devices, with the i2c ports that are statically defined in devicetree.
However, auto-connection for i2c can still be used in embedded devices, with the i2c ports that are statically defined in devicetree.
I’m not sure I’m fully understanding the complete scenario. It would be great if you could develop it a more.
With my current (possibly wrong) understanding, for the embedded device use case, it sounds like the i2c port permission should be granted to the gadget snap instead.
My understanding of this app is that it is running on a desktop machine and actually flashing beaglebone images to the emmc of the board through a serial USB connection. I have a hard time to understand where i2c or hidraw come into play with this (both would be typically used on the device but not on the desktop that sends the image over the serial connection)…
On the desktop where the app runs the slots would not be available (since there is no gadget providing them) so there is simply nothing to connect to.
bb-imager is used to flash both MCUs and SBCs. Specifically here what is used to flash different types of images to different boards:
udisks2: SD card flashing. Mainly for Linux distro images. But sometimes U-boot + Zephyr.
hidraw: BeagleConnect Freedom internally has a MSP430, which acts as USB to UART. The firmware on MSP430 can be changed to something else. It has a Bootstrap loader internally, that shows up as hidraw when connected over USB and put into BSL mode.
i2c: Upcoming MSPM0 based BeagleConnect Zepto is normally flashed using the built-in bootloader. This can be done over 2 transports: i2c and uart. i2c is normally used by some people when things are connected of QWIIC cable.
Wait, so the default i2c gadget snap is only available on ubuntu core, and not when using snap on normal Debian/Ubuntu?
I am trying to confirm some things but well, the snapcraft Rust plugin seem to have broken recently. I am trying to pin down what exactly happened.
Just to get the wording right: every Ubuntu install has a gadget snap (classical .deb based installs as well as snap based Ubuntu Core ones).
Interface slots that are specific to the underlying hardware have to be defined in these gadget snaps (while other more generic ones come from snapd)…
Since the gadget on core is usually very specifically tailored to the underlying board they usually define such things but on classic Ubuntu installs that aim to be installable generically on as much hardware as possible such specific interface slots are omitted (not every PC has i2c and the device names might vary)