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.
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?
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.)
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?
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.
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.
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.
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
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
:) I knew it was something obvious I was overlooking.
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.
Created attachment 1799359 [details] Add some more information to the alias
https://src.fedoraproject.org/rpms/kernel-srpm-macros/pull-request/5
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).
Swinging back around to this, any thoughts?
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?