New Tracks for xlnx-config snap

I’d like to request two new tracks for the xlnx-config snap: 1.x - used with 20.04 image 2.x - used with 22.04 image

The functionality we provide in xlnx-config snap will be different for each of our Certified Ubuntu images (22.04 comes out next week). I plan to use the latest track for the xlnx-config 2.x updates for our 22.04 release, and I’ll move the current xlnx-config v1.1 to the 1.x track. I’ll also make xlnx-config 2.x available on the 2.x track.


Thanks, Terry


xlnx-config has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have a few questions before casting my vote.

  1. What’s the release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream? Does this depend on e.g. a new Ubuntu release coming out, with a presumably new kernel?
  2. Is there some commitment from upstream on maintenance of old versions?
  3. Can you provide some detail as to why 1.x is only compatible with 20.04 and 2.x only compatible with 22.04? Do they depend on kernel features? would it be feasible to use bases instead, so e.g. 1.x can use base: core20 and be installable on 22.04-based systems?

I think in general I understand your use case, and given that xlnx-config is somewhat closely tied to hardware, which in turn means a specific kernel, which further points to it heavily depending on which kernel the system ships, I’m mostly OK with granting the track, as we have seen this pattern and there’s precedent for doing things this way.


  • Daniel

Hi @roadmr - xlnx-config is a classic snap that runs only on AMD/Xilinx development boards, and is responsible for manipulating the boot firmware such that multiple versions of the programmable logic can be deployed and switched between. It also provides some xilinx-specific system initialization scripting that is ubuntu-release specific.

  1. It’s likely that we’ll create a new release for each Certified Ubuntu Image that we release for Xilinx devices, but it will depend on how our boot firmware architecture evolves. It’s possible that the 2.x track might still be used in the next image, but very hard to say at this time.

  2. I plan on maintaining the old versions and would like to be able to provide bug fixes for the older versions so developers that remain on 20.04 (after our 22.04 release), for example, can get updates.

  3. We’ve changed the boot firmware architecture quite a bit from the 20.04 image when moving to 22.04. It would require quite a lot of extra code to handle multiple architectures. We discussed with our Canonical contacts and determined that tracks would be a better route.

Regards, Terry