The major obstacle right now is supporting the device controller. In cgroup v1, it was controlled by writing textual information about a device to a file under the cgroup controller. With v2, the files are gone, and one needs to attach an eBPF program that implements the functionality. Hopefully it’s as simple as concatenating a static prologue/epilogue with a bunch of direct jumps in between.
As for some easier things still in the TODO list, there’s missing support for the freezer, which is no longer a separate controller, but there’s a single cgroup.freeze file that you write to. The support needs to be added to snap-confine and snap-update-ns (via sandbox/cgroup package).
eBPF isn’t really “extended BPF” anymore, it’s functionality has gone well beyond just packet filtering rules. The way I’ve read it is it’s better to just treat eBPF as its own buzzword rather than a literal extension to BPF. I think here is a good overview
Basically, the whole reason I started this thread is because I am on Fedora. ) It was not problematic until I got into problem with packaged Electon app (matrix.org client) where it is not clear if the problem is in packaged software itself, its dependencies or in the incomplete cgroup v2 support in snapd.
I thought that cgroup may be involved, because the log of errors on stdout starts with this big warning that cgroup v2 is not full supported yet. It is shown every time a snap is started, but this time the app could not even show a window.