Re: [H-source-users] [PATCH 6/6] Add Guix system with GNU/Hurd to the distro list

[Denis 'GNUtoo' Carikli]

On Sun, 26 Jun 2022 07:09:38 -0400
bill-auger <bill-auger@peers.community> wrote:

> i would object to this change, as it is - i think it is heading
> in the wrong direction - merely using a different kernel, does
> not make a different distro - guix+linux-libre or guix+hurd is
> the same distro in every meaningful way
Right, people could indeed just set Guix as the distribution and Hurd
as the kernel to get the exact same result.

The only drawback with not adding Guix + GNU/Hurd as distribution is
that the kernel names are not normalized, but avoiding duplication
(between the distro name and the kernel) and a better data model (where
the kernel field describe the kernel and the distribution fields
describe the distribution) looks more important here.

> the important information to capture is the kernel itself, and
> which module is in use by each hardware; because that is what
> actually determines the essential question of: "does this
> hardware work with free software?" - the distro names are purely
> informative - 
It depends on the cases. Many computers with Radeon GPUs are better
supported with Jxself's linux-libre but not with Trisquel 10 because
Trisquel 10 has patches on top of Linux-libre that disables some of the
Radeon patches.

For some other computers it could also be the opposite (they'd work
better with an unmodified Trisquel) due to these exact same patches
(Xorg needs a specific configuration for Radeon GPUs that lack 2D
acceleration, and that's not provided in any distribution so far).

So in this precise example, the exact kernel version is not that
important as the patches were there in linux-libre since a long time
ago, and I still didn't find the time to do the work required to fix
that in Trisquel to re-add support for some specific Radeon GPUs in
Trisquel.

> the change we should be working toward is to make
> linux-libre, the debian kernel, and hurd as the canonically
> recognized kernels, rather than having that information as an
> arbitrary text field (or simply deduced from the "Guix+Hurd"
> distro name), 
Indeed, that would be better than this patch, but I'm not sure if
it's really necessary. My fear here is that it too much field could
would confuse users (the same applies to having Guix HURD too).

So maybe there is another way: somehow deducing the exact kernel package
used from uname -a or uname -r? I'm not sure how to do that though.

If somehow we have a database of kernel version strings that could
give, with the string as input, the distribution version, and the
exact package used, that would be great.

For instance 5.17.9-gnu-1-pae would give Parabola i686 stable (not
testing, etc) and libre/linux-libre-pae 5.17.9-1.

And Parabola would guarantee that there is only 1 package
libre/linux-libre-pae 5.17.9-1 package ever published and that only
that package reports 5.17.9-gnu-1-pae in uname -r.

This way we could use that to try to reproduce the working state if
needed.

If Jxself's repository is used it would also show in the strings and we
would also be able to somehow map the string with the exact kernel
package used.

I'm not sure how it would work for Guix, but at least for distributions
that have fixed releases for either packages files (like Parabola) or
images (like Replicant) we could come up with strings unique to a given
package version.

Replicant at least up to 6.0 (included) is not reproducible, so the
kernel uname -a is unique, and we already have some "database" of kernel
string (uname -a) <-> released image correspondence[1] that we create
for other reasons (in Replicant, the version + target device is
sufficient to identify the software being used).

What is more tricky is the architecture (i686, x86_64, etc), and here
I'm not sure how to do it: uname -a has it but it also contains private
information (like the hostname), and uname -r doesn't have it.

Maybe we need to encode the architecture in the kernel extra version?

For clients lshw is really interesting as it can retrieve a lot of
data. As I understand it it's used by Red Hat for a farm of test
machines, and here they even want to capture all details up to the BIOS
exact version or HDD firmware version, though the level of details also
has some privacy implications.

> and to start white-listing kernel modules in the same way (and hurd
> modules, if there is any difference in those sets) - AFAIK, the
> kernel modules (or whatever hurd calls them) are the same ones taken
> from linux
The issue here is that there are sometimes a many to one relationship
between the module name and the module. For instance both 'modprobe
ath9k_htc' and 'modprobe ath9k-htc' work. And sometime they are used
interchangeably.

In addition some drivers are pretty modular. For instance there is
ath9k_hw, ath9k_common and ath9k, and you need these 3 modules.

So here I'm not sure how to handle that. Maybe we could generate a list
by looking at modules that are not "Used by", but I'm not sure if it
would work for all modules.

Here with both ath9k_htc and ath9k aren't "used by" so it works at
least in this case:
> $ sudo lsmod
> Module                  Size  Used by
> [...]
> ath9k_htc              69632  0
> [...]
> ath9k                 139264  0
> ath9k_common           36864  2 ath9k_htc,ath9k


> like the point i raised on the other thread WRT there being 3
> distinct entries which could represent a debian unstable system,
> an arbitrary change like this one is not so obviously
> problematic, if you assume that people will be entering all the
> information manually on the web, or that people will not want to
> search/sort by a canonical kernel or distro name - but more
> importantly, from the perspective of the h-client, which can
> help to normalize rogue entries with sane constraints, it is not
> clear how to handle these arbitrary additions - indeed, it
> suggests that we should not - but instead, to re-think the
> database schema, to capture the important information better, and
> possibly to relax the less important information
One of the use cases here could be to find hardware that strangely works
in one configuration and doesn't in another or vice versa.

But you're right on the fact that the website should not become too
complicated to use. Some users might indeed not know what HURD is for
instance.

> we should be thinking of ways to make the important data less
> general (such as not allowing users to enter the kernel module
> information arbitrarily, but letting the software determine
> that, or via a select/options widget on the website),
> and to make the less important data more general (such as
> un-constraining the distro names, by adding an arbitrary "other"
> distro class and a text field on the website to enter
> "my-distro-name", but presenting all currently white-listed
> distros as a select/options widget)

I've already written code (in python) that can recreate the output of
lspci just with the PCI ids[2], so we could potentially only store what
is not in /usr/share/hwdata/pci.ids, though I've no idea how to find the
driver from that progmatically.

I typically do it by grepping Linux by hand

For instance we have things like that:
> static const struct pci_device_id dwc3_pci_id_table[] = {
>         { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BSW),
>           (kernel_ulong_t) &dwc3_pci_intel_swnode, },
>         [...]
>         {  }    /* Terminating Entry */
> };
> MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
> 
> static struct pci_driver dwc3_pci_driver = {
>         .name           = "dwc3-pci",
>         .id_table       = dwc3_pci_id_table,
>         .probe          = dwc3_pci_probe,
>         [...]
> };
> [...]
> 
> module_pci_driver(dwc3_pci_driver);

Here PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BSW) means 8088:22b7 (the
id can be seen with lspci -nn).

That table might end in a separate section of the Linux binary that
could probably be parsed somehow, though if it would require to write
the code for that and it's probably not trivial.

Or maybe there is some other way to extract that code somehow with
coccinelle / spatch or even grep and then parse it?

References:
-----------
[1]https://redmine.replicant.us/projects/replicant/wiki/ImagesIdentification
[2]https://framagit.org/GNUtoo/hardware_list.git in utils/lspci.py
   under the AGPLv3+

Denis.

pgpDLGrGEJ_QM.pgp
Description: OpenPGP digital signature