Request for dfx-mgr-socket as system-files autoconnection for FGPAd snap

store-requests privileged-interfaces
1
  • name: fpgad
  • description: FPGA utility that manages bitstream[^1] loading and unloading
  • snapcraft: fpgad/snap/snapcraft.yaml at main · canonical/fpgad · GitHub
  • upstream: GitHub - canonical/fgpad
  • upstream-relation: maintainer
  • interfaces:
    • system-files:
      • request-type: auto-connection
      • reasoning: For when running on AMD xilinx boards, we have implemented the full upstream functionality of their proprietary solution (dfx-mgr) by using their binaries as a backend for fpgad. dfx-mgr is a client/daemon system which uses the socket at /run/dfx-mgrd.socket for communication and therefore we require RW access to this file.

[^1] Bitstreams are binary blobs that configures FPGA devices

interface definition:

  dfx-mgr-socket:
    interface: system-files
    write:
      - /run/dfx-mgrd.socket

Note that I tried using layouts and this is prohibited for files in /run/ . Please let me know if there is a preferred solution which is not this.

Thanks in advance, and don’t hesitate to ask if anything isn’t clear Best, Artie (& Talha)

2

I’m sorry for failing to tag Request for dfx-mgr-socket system-files autoconnection for FGPAd snap Also please see previous requests:

3

This request has been added to the queue for review by the @reviewers team.

4

After some discussion with @artiepoole, both mgrd and dfx-mgr-client are provided by a snap component. They communicate over /run/dfx-mgrd.socket as stated in dfx-mgr/README.md at master · Xilinx/dfx-mgr · GitHub

Could you change the interface name to match our usual name convention (i.e. run-dfx-mgrd-socket)? Other than that, it looks good to me (+1 from me)

Thanks

5

Thanks Jorge! RE socket name: root: workflows: rename dfx-mgr socket interface to match convention by artiepoole · Pull Request #206 · canonical/fpgad · GitHub

6

+1 from me too, it makes sense for system-files interface auto-connection for this snap to have write access on run/dfx-mgrd.socket. (#voteFor)

thanks

7

+2 for, 0 against granting fpgad the write access to /run/dfx-mgrd.socket via auto-connection of system-files interface. This is now live.

Note that the snap is still failing with an error and a warning. The error is related to the other system-files interface. In previous snap revisions this interface was defined as

  device-tree-overlays:
    interface: system-files
    read:
    - /sys/kernel/config/device-tree/overlays
    write:
    - /sys/kernel/config/device-tree/overlays

whilst in new revisions this is now

  device-tree-overlays:
    interface: system-files
    write:
    - /sys/kernel/config/device-tree/overlays

Both are equivalent permissions wise, however review-tools exactly match attributes in the snap.yaml and the snap-desclaration. I cannot simply update the snap-declaration to match this new definition as this will cause regressions with snaps using the old definition (which are now in all snap channels). Thus, you will need to revert this to keep using the previous interface definition.

Regarding the warning, this is review-tools not knowing about the hooks you are using for components. Let me clarify with snapd folks what new hooks have been introduced to support snap components

Thanks

8

Thank you very much @jslarraz

To address the review tool issue:

Thanks again

Edit: we have investigated build failures due to dfx-mgr not being available for all architectures we target. We will address this in the PPA. jq snap doesn’t exist for riscv (in stable at least) so we will have to figure this out too.