Device driver in a snap package


#1

Is it possible to distribute a device driver in a snap package? For example, if the snap package will contain a module for the kernel?


#2

No I don’t believe that would be possible. A snap is self-contained within the “snap” script itself. You might be able to accomplish this by using the snap as a sort of update manager and download a separate script to run externally.


#3

Maybe I’m wrong, but I think it is possible to do.
This would simplify the distribution of drivers, for example for graphics cards.


#4

Unless the driver is a user space driver that wouldn’t be possible as Linux kernel don’t maintain In-kernel APIs.


#5

Stop, explain to me then what is the difference between the installation, for example, of the amdgpu-pro from the larger set of DEB packages, in which there are libraries and modules that are connected to the kernel, and if this is running from the snap package?


#6

The graphics driver consists of both user space and kernel space components, the kernel space component’s compatibility of the amdgpu-pro driver also subject to the in-kernel APIs.


#7

With the AMDGPU Pro drivers they utilize the same in-kernel code as the open source AMD drivers which expose an api that AMD can rely to be consistent.

Related drivers from nVidia are compiled on every system a user installs them onto. They are subsequently recompiled for every kernel that is installed thereafter. This compilation happens on the user’s machine not the repository builders.

The mechanism that nVidia drivers use on Debian derivative distributions is called DKMS.

Drivers that are shipped with a kernel are tied explicitly to the kernel they shipped with so they are compiled at the same time, which is partly why their source is maintained as part of the kernel tree. The other reason being simplicity for development and distribution.


#8

Do you have plans to implement work with DKMS in snapd?


#9

DKMS is not related as it is simply a mechanism that rebuilds the kernel module during kernel upgrades, if the kernel module isn’t compatible in the first place it won’t work.

Proprietary drivers can be built with a wider range of kernel versions is the result of the conditional building against each of the supported in-kernel APIs and will still break with exotic kernels.