Module blacklisting interface?

In the course of working out how to get a few different smartcard readers to work with pcscd (packaged as “pcsc-daemon” in the store now) to make reading government IDs, passports, NFC tags and smart cards easily possible on Ubuntu Core I ran into a good bunch of devices where the kernel module actually breaks the userspace USB driver.

The install instructions for many of these devices (not all of them indeed, else the kernel module would be pointless) do often start with “first of all create an /etc/norprobe.d/blacklist-pcscd.conf file containing the line ‘blacklist pn533_usb’” …

It struck me that we do not have any ability for users/customers to actually handle such module blacklisting (beyond giving full rw access to /etc/modprobe.d through a system-files interface or some such)

@jdstrand suggested i should start a discussion about how to handle such blacklists more cleanly…

A gadget default, an interface so a gadget could run a script, a system option you could use with snap set come to mind …

What is the best way forward here ?

It feels a bit like this is something that both the kernel snap and the system admin should have voices in, in that some kernel snaps may require a given module to be loaded in order for the kernel to work properly on the device, so I think a naive snap set system excluded-kernel-modules=[foo,bar] would have to somehow check with the kernel snap to make sure that it’s okay to exclude foo and bar, which also means that the kernel snap needs to convey this information to snapd somehow, perhaps through the snap.yaml specifically for snaps of type: kernel.

1 Like

What a coincidence, I’m trying to enable a new version of the board I’m working on, and I’ve found myself with a problem that might require blacklisting to solve/debug. Still have a lot of research to do, but I will be following this topic closely, as I would like an answer.