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 16:57:16 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> > 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
> > 
> > For some other computers it could also be the opposite (they'd work
> > better with an unmodified Trisquel) due to these exact same patches
> > 
> > So in this precise example, the exact kernel version is not that
> > important as the patches were there in linux-libre  
> 
> yes that is getting at the heart if the matter - i dont think
> that is precisely the case though - AFAIK, trisquel takes the
> ubuntu kernel source package and de-blobs the sources with a
> "package-helper" script (like makeicecat) - so it is not the
> FSFLA's linux-libre - it is also distinct from the debian kernel
I looked for Trisquel 10 and there was a mix of different things, and
linux-libre was also involved but some of its changes were reverted.

> "trisquel the distro" is not the essential factor - the
> essential factor is that kernel which _incidentally_ comes
> pre-installed on a default trisquel system - regardless of the
> distro used, a pureos user for example could install that
> trisquel kernel if necessary; or a trisquel user could install
> linux-libre or the debian kernel
Both are important. For a printer or a scanner, "Trisquel 10" is more
relevant because the important parts are rather in sane or cups drivers.

> so my idea is to make those kernels distinguishable somehow like
> tested with:
> * debian linux 5.11
> * trisquel linux 5.11
> * linux-libre 5.11
> * hurd 1.2.3
Maybe "Debian with Linux 5.11" is better as it avoids the confusion
between Linux and GNU/Linux.

And to improve it more, maybe "Debian i686 with Linux 5.11" is even
better as it would tell which architecture of Debian is installed.

And we could have "Trisquel x86_64 with Linux 5.11" or "Trisquel with
jxself's linux 6.0" for instance.

And for Hurd it would be "Guix with Hurd 1.2.3".

> On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> > 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).  
> 
> again, i am not concerned with the website, where the correctness
> of the contribution depends on the user's knowledge and honesty
> - i am considering making the client determine which kernel and
> modules are loaded - if the user notices that the client made an
> incorrect guess, it would suggest opening a bug report
Good point.

> for the website, i am thinking about a "drop-down"
> select/options widget for the website - it could be pre-loaded
> with exactly 4 kernel options (let the user type the version)
> * debian linux
> * trisquel linux
> * linux-libre
> * hurd
Or we could simplify it and just let the user copy a string from uname
-r. 

The distributions would have to make sure to adhere to some standard
though so that the string uniquely identify a kernel package or build.

The good thing is that we have few distributions supported so it might
be possible to make all 100% free distro use that. 

> On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> > The issue here is that there are sometimes a many to one
> > relationship between the module name and the module.  
> 
> maybe not; but it is probably safe to assume that lsusb/lspci is
> going to report _something_ - whatever lsusb/lspci reoirts, that
> is what the user would type by hand anyways;
Good point, we could standardize on that. 

> so the information
> would be at least as reliable as it is now  - its just a matter
> of white-listing the possible names, rather than letting it be
> an arbitrary text field - then there would be no doubt that the
> field contained the name of a known libre module, rather than
> someone using a non-free wifi device on debian for example, and
> reporting it as "working" with a non-free module
Right. Note that we also need to whitelist modules that typically
depend on nonfree firmwares: in case they somehow work without them, we
don't want to miss that.

> and perhaps not knowing or forgetting that the non-free formwars
> package is installed - h-client could even check for that, in
> case the device is working; but lsusb reports an empty "module
> in use" name

In one of my computers I have:
> 0000:01:00.0: Missing Free firmware (non-Free firmware loading is
> disabled)
> r8169 0000:01:00.0: Unable to load firmware /*(DEBLOBBED)*/ (-2)
So not only that should be relatively easy to grep but we might even be
able to get the PCI device address (0000:01:00.0) and the driver
(r8169).

And since the Ethernet works fine on that computer, we know that it
works fine without the firmwares.

With debian it might be a bit more tricky to grep.

> On Sun, 26 Jun 2022 21:49:30 +0200 Denis wrote:
> > 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.  
> 
> the h-client already determines the VID:DIDs and which module the
> device is using, by shelling out to lspci and lsusb and parsing
> the outputs
Ah ok.

I've found how to do it by reading lspci manual:
>        -p <file>
>               Use <file> as the map of PCI ID's handled by kernel
> modules.  By  default,  lspci  uses  /lib/modules/kernel_version/mod‐
> ules.pcimap.  Applies only to Linux systems with recent enough module
> tools.

However when thinking about it, this is probably not what we want to do
as it would only give us potential drivers being used, and doing that
retrospectively would also not be a good idea since it's up to the user
to validate that the driver suggested by h-client is the one really
being used.

And I've looked again and lspci now also has an option to show the
driver in use (Example: "Kernel driver in use: ath9k") which is
different from the list of potential drivers that it can also show
(Example: "Kernel modules: ath9k").

Though I've not looked at the h-node code that use lspci recently.

Denis.

pgpCBzDCLt1Bn.pgp
Description: OpenPGP digital signature