[SRU kernel-snaps-uc24.04/pc][RFC PATCH v2 1/2] snapcraft.yaml: Add nvidia-550 and nouveau component support

[Aaron Jauregui]

Agree on most points, just have some bits of clarification regarding
some of the comments.

Where would be a good place to write a more comprehensive architectural
overview and testing plan? Would the cover letter be appropriate?

On Tue, Dec 10, 2024 at 01:20:01PM +0100, Juerg Haefliger wrote:
> > +
> > +  nvidia-550-user:
> > +    type: standard
> > +    summary: nvidia 550 userspace libraries
> > +    description: nvidia 550 userspace libraries
> > +
> > +  nouveau:
> 
> For consistency, this should be nouveau-ko. But why do we need this? Can't we
> just move the nouveau driver out of the way when nvidia-550-ko is
> installed and move it back on removal?

The nvidia components use the -ko and -user suffixes since both are
required for the driver to work, but are distinct pieces. I think in
nouveau's case having the component's type be kernel-modules is enough
to distinguish it as being ko objects. The -ko suffix feels a bit
superfluous, but happy to make the change if deemed necessary.

Moving the nouveau driver out of the way wouldn't be possible from the
main snap, as it is read-only. To prevent having both nvidia-550 and
nouveau kernel objects installed at the same time, we are putting both
in the same location ($SNAP_DATA/modules/$(uname -r)/graphics).
Following this pattern with future nvidia versions will mean only one is
active at a time. The intention is to think of the nouveau component as a
special case of nvidia components.

> 
> > +    type: kernel-modules
> > +    summary: nouveau kernel module
> > +    description: nouveau kernel module
> > +
> >  parts:
> >    kernel:
> > -    source: https://git.launchpad.net/canonical-kernel-snaps
> > +    source: https://git.launchpad.net/~aaronjauregui/canonical-kernel-snaps
> >      source-type: git
> >      source-branch: main
> >      plugin: nil
> > @@ -42,6 +58,39 @@ parts:
> >  
> >        craftctl default
> >  
> 
> IMO, all the below shouldn't really be part of the build step, it is staging.

I don't think this would be possible. Files are moved into components at
the organize stage, which happens before staging.

> > +      rm -f -- $CRAFT_PART_INSTALL/usr/lib/$(uname -m)-linux-gnu/libc.so.6
> 
> Why?

I was running into problems with both the component and the parent snap
having libc versions that would conflict. I intend to do further pruning
soon, as I don't think all the utilities shipped with this component are
necessary.
 
> 
> Finally:
> - You're moving and adding kernel modules. Don't you need depmod somewhere?
> - Have you tried to build this on arm64?

snapd takes care of running depmod for any component of the
kernel-modules type. This feature is only enabled by having a line in
meta/kernel.yaml declaring "dynamic-modules: $SNAP_DATA". This is also why
the files block dumps this into the snap.

All launchpad builds for components also build for arm64. Builds seem to
complete with no issues, but I have not yet tested on arm64.

Cheers, Aaron