Re: [H-source-users] generalize (or eliminate) the distros white-list

[Denis 'GNUtoo' Carikli]

On Tue, 2 Nov 2021 19:41:53 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Mon, 01 Nov 2021 21:29:26 +1100 Yuchen wrote:
> > How do you handle the case where the free firmware supporting a 
> > piece of hardware is not in the kernel
> >
> > Would you amend the definition from "works with this kernel" to 
> > "works with some free firmware that works with this kernel"?
> 
> IMHO those mean the same thing - those firmware are not "in the
> kernel" - they are modules, distributed along with it (or not) -
> "works with this kernel" is still the only significant factor
> for anyone - some may need to acquire the module (eg: if their
> distro lacks it) - - its not important how one gets the module;
> yet "works with this kernel" strongly suggests that it can be
> made to work on any distro with that kernel
> 
> the missing or confusing bit of information in that example,
> would be the distro - "works on this distro" (either Yes or No),
> would be misleading, if that distro does not install some module
> with the kernel package, or if the user added it manually
It is possible to autodetect the driver used for a specific hardware.

For instance for a network interface, you can do the following in the
shell:
> basename $(readlink /sys/class/net/<interface>/device/driver)
with interface being something like eth0, wlan0, and so on.

For PCI(e) you can do it with a similar command:
> basename $(readlink /sys/bus/pci/devices/0000:00:02.0/driver)
Here you need to replace 0000:00:02.0 by the bus ID you want. These
also show up in lspci.

For USB it's also similar to PCI.

To know if the driver is stock we could probably get the information
from the module taint file[1]:
> What:           /sys/module/*/taint
> Date:           Jan 2012
> KernelVersion:  3.3
> Contact:        Kay Sievers <kay.sievers@vrfy.org>
> Description:    Module taint flags:
>                         ==  =====================
>                         P   proprietary module
>                         O   out-of-tree module
>                         F   force-loaded module
>                         C   staging driver module
>                         E   unsigned module
>                         ==  =====================

So we could give out simple commands and/or implement that in h-client
or through scripts that works on all the distributions (portable shell
scripts are really hard to code though).

So for instance my GPU works fine, and it uses the i915 driver / module:
> $ basename $(readlink /sys/bus/pci/devices/0000:00:02.0/driver)
> i915
So I can look if the kernel driver is the stock one in this way:
> $ cat /sys/module/i915/taint
> [nothing]

It's in a Thinkpad X200:
> $ cat /sys/class/dmi/id/product_family
> ThinkPad X200

And that computer runs Coreboot 4.13:
> $ cat /sys/class/dmi/id/bios_vendor
> coreboot
> $ cat /sys/class/dmi/id/bios_release 
> 4.13

Though I've local modifications, so that isn't really seen here, but
they don't touch the GPU at all.

And I've mesa 21.2.1-1.0
> $ pacman -sS ^mesa$
> extra/mesa 21.2.1-1.0 [installed]
>     An open-source implementation of the OpenGL specification
Here it's a bit tricky, as we don't have an abstraction that works
in all FSDG compliant distributions.

Packagekit should work fine on Hyperbola, Parabola, PureOS, and
Trisquel. It's known not to be implemented yet for Guix, and it's
probably not implemented for Dragora as it's a custom distribution with
a custom package manager. It doesn't seem to have a backend for 'opkg',
so LibreCMC probably doesn't work either.

For the kernel version we have 'uname -a', 'lsb_release -a' for the
distribution version and so on.

For Replicant, all that could be handled just by looking at the
Replicant version as upgrade are made by installing new versions of the
distribution. That probably applies to Dynebolic too.

In any case if we have a text field per "test", users could also add
any relevant information there if they know how to obtain it. This way
it would also accommodate all uses cases and require less coding,
though the downside is that the information there would be less
structured, so it would be less easy to find regressions by just
analyzing the data.

References:
-----------
[1]From Documentation/ABI/testing/sysfs-module in the kernel source
   code. It can also be viewed online at the kernel git[2].
[2]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-module
   Note that while this file contains no nonfree firmware, part of the
   Linux kernel might contain some.

Denis.

pgp6MfuE7nTO6.pgp
Description: OpenPGP digital signature