Bug 1976971 - [RFE] kmod "alias" provides for hardware support
Summary: [RFE] kmod "alias" provides for hardware support
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-srpm-macros
Version: rawhide
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Eugene Syromiatnikov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-28 16:42 UTC by Pat Riehecky
Modified: 2023-01-27 11:13 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Example patch (546 bytes, patch)
2021-06-28 16:42 UTC, Pat Riehecky
no flags Details | Diff
Add some more information to the alias (1.38 KB, patch)
2021-07-07 16:59 UTC, Pat Riehecky
no flags Details | Diff
Add some more information to the alias (1.38 KB, patch)
2021-07-07 17:08 UTC, Pat Riehecky
no flags Details | Diff

Description Pat Riehecky 2021-06-28 16:42:11 UTC
Created attachment 1795492 [details]
Example patch

Description of problem:

The existing kmods have a field denoting what hardware or other devices they support (via the modinfo alias).  It would be helpful for hardware enablement to have these exported where they can be easily querried.

Version-Release number of selected component (if applicable): 1.0-5


How reproducible: 100%


Steps to Reproduce:
1. Try to locate a drive for a specific piece of hardware via the IDs
2.
3.

Actual results:
Not a great way to instrument dnf/rpm to look for hardware drivers.

Expected results:
List of IDs (mostly pci or usb) with provided drivers in the distribution.


Additional info:

I've attached a patch that I think comes close for the `readelf` case.  I've no idea how to make `nm` do this type of thing....

In cases where multiple drivers can cover the same IDs I think it would be helpful if the Provides was tagged with the version.  Mostly so folks can eventually distinguish between nouveu and nvidia.

Comment 1 Peter Georg 2021-06-28 21:56:10 UTC
I might misunderstand your intentions, but isn't modalias.prov (https://src.fedoraproject.org/rpms/kernel-srpm-macros/blob/rawhide/f/modalias.prov) offering something very similar?

Comment 2 Troy Dawson 2021-07-01 15:22:11 UTC
Pat, any thoughts on Comment #1 ?
Will the modalias do the job, or do you think it is missing features that this patch gives?  (Or possibly not even close to what you want.)

Comment 3 Pat Riehecky 2021-07-01 16:20:44 UTC
I'll need to dive into it a bit more.  Is there a bug I can watch for getting this macro turned on for the kernel package?

Comment 4 Pat Riehecky 2021-07-02 13:07:12 UTC
I may be doing it wrong, but I don't seem able to get that macro to produce any rpm provides...

Tested on Fedora 35.

Comment 5 Peter Georg 2021-07-02 14:16:52 UTC
I can confirm it is not working in Fedora (running 33 here). On CentOS Stream 8 it is working.

Digging into it, this seems to be a bug:
Only scripts in find-provides.d with executable bit set are executed (see https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/find-provides#_20).
However the modalias.prov is set as 0644 (see https://src.fedoraproject.org/rpms/kernel-srpm-macros/blob/rawhide/f/kernel-srpm-macros.spec#_73)

I can create a bug report later.

Comment 6 Peter Georg 2021-07-02 16:25:37 UTC
Created a PR for the bug mentioned above: https://src.fedoraproject.org/rpms/kernel-srpm-macros/pull-request/3

Note: This only fixes the bug after https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/134 is merged as well.

Comment 7 Pat Riehecky 2021-07-07 15:27:59 UTC
I've gotta be doing something obvious wrong.....


mock -r centos-stream-8-x86_64  --rebuild https://elrepo.org/linux/elrepo/el8/SRPMS/kmod-3w-xxxx-2.26.02.003-5.el8_4.elrepo.src.rpm


the resulting rpm doesn't seem to have any alias Provides

$ rpm -qp --provides kmod-3w-xxxx-2.26.02.003-5.el8.elrepo.x86_64.rpm 
config(kmod-3w-xxxx) = 2.26.02.003-5.el8.elrepo
kernel-modules >= 4.18.0-305.el8.x86_64
kmod-3w-xxxx = 2.26.02.003-5.el8.elrepo
kmod-3w-xxxx(x86-64) = 2.26.02.003-5.el8.elrepo


but the ko object does have them:

$ rpm2cpio kmod-3w-xxxx-2.26.02.003-5.el8.elrepo.x86_64.rpm | cpio -idm
$ modinfo ./lib/modules/4.18.0-305.el8.x86_64/extra/3w-xxxx/3w-xxxx.ko
filename:       /builddir/build/RPMS/./lib/modules/4.18.0-305.el8.x86_64/extra/3w-xxxx/3w-xxxx.ko
version:        1.26.02.003
license:        GPL
description:    3ware Storage Controller Linux Driver
author:         LSI
rhelversion:    8.4
srcversion:     DE4DB2383BA67218D793CD2
alias:          pci:v000013C1d00001001sv*sd*bc*sc*i*
alias:          pci:v000013C1d00001000sv*sd*bc*sc*i*
depends:        
name:           3w_xxxx
vermagic:       4.18.0-305.el8.x86_64 SMP mod_unload modversions

Comment 8 Peter Georg 2021-07-07 15:50:42 UTC
The src.rpm you linked to explicitly sets find provides to:
%define __find_provides /usr/lib/rpm/redhat/find-provides.ksyms %{kmod_name} %{?epoch:%{epoch}:}%{version}-%{release}

I.e. it does not call /usr/lib/rpm/redhat/find-provides for provides, which in turn would then call find-provides.ksyms and all executable scripts in /usr/lib/rpm/redhat/find-provides.d/*.prov (including modalias.prov).

I just verified myself. Rebuilding the src.rpm you linked I get:

$ rpm -qp --provides kmod-3w-xxxx-2.26.02.003-5.el8.elrepo.x86_64.rpm 
config(kmod-3w-xxxx) = 2.26.02.003-5.el8.elrepo
kernel-modules >= 4.18.0-305.el8.x86_64
kmod-3w-xxxx = 2.26.02.003-5.el8.elrepo
kmod-3w-xxxx(x86-64) = 2.26.02.003-5.el8.elrepo

After removing line 26 of the spec file, I get:

$ rpm -qp --provides kmod-3w-xxxx-2.26.02.003-5.el8.elrepo.x86_64.rpm 
config(kmod-3w-xxxx) = 2.26.02.003-5.el8.elrepo
kernel-modules >= 4.18.0-305.el8.x86_64
kmod(3w-xxxx.ko)
kmod-3w-xxxx = 2.26.02.003-5.el8.elrepo
kmod-3w-xxxx(x86-64) = 2.26.02.003-5.el8.elrepo
modalias(pci:v000013C1d0000100[01]sv*sd*bc*sc*i*) = 1.26.02.003

Comment 9 Pat Riehecky 2021-07-07 16:33:59 UTC
:) I knew it was something obvious I was overlooking.

Comment 10 Pat Riehecky 2021-07-07 16:59:53 UTC
Created attachment 1799323 [details]
Add some more information to the alias

Now that I've got the macro working, it is super close to what I'm looking for.

I've attached a new patch to add a bit more metadata so I can distinguish more easily between overlapping aliases.

Comment 11 Pat Riehecky 2021-07-07 17:08:22 UTC
Created attachment 1799359 [details]
Add some more information to the alias

Comment 13 Eugene Syromiatnikov 2021-11-23 00:02:15 UTC
Not sure if using kmod name as a version is a good thing. Moreover, it has to be filtered out of any dashes (and other non-suitable characters), at least, as RPM dependency tag version cannot contain more than one dash (as version/release separator).

Comment 14 Pat Riehecky 2023-01-24 16:59:34 UTC
Swinging back around to this, any thoughts?

Comment 15 Peter Georg 2023-01-27 11:13:17 UTC
Apart from the concerns voiced by Eugene Syromiatnikov concerning using the kmod name as a version due to required filtering, I do not fully understand the motivation for your proposed changes.

Assuming I understand it correctly you want to add, in addition to the existing modalias provides, a modalias provides which in addition to the kmod version also contains the kmod name.
Your argument to add these is to allow users to distinguish between different kmods providing support for the same device(s). A particular example is nouveau vs. nvidia. For this particular example this information can probably also be obtained from the kmod's version and/or the package which provides the kmod respectively the modalias you have been searching for, e.g., using dnf whatprovides. For nouveau this would be kernel-modules, for nvidia probably kmod-nvidia-* or similar.

In case of both kmods not being part of any of the kernel-* packages but provided by their own kmod-* package the distinction is even easier. In this case adding the information as suggested would, in my opinion, only add redundant information.

Not sure it is worth adding this information for all kmods despite it only being useful for very specific cases?


Note You need to log in before you can comment on or make changes to this bug.