Page MenuHomeFreeBSD

net/wifi-firmware-kmod: remove obsolete kernel module build code
Needs ReviewPublic

Authored by bz on Tue, Nov 11, 1:31 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 1, 2:37 AM
Unknown Object (File)
Fri, Nov 28, 10:24 AM
Unknown Object (File)
Fri, Nov 28, 6:09 AM
Unknown Object (File)
Wed, Nov 26, 9:39 AM
Unknown Object (File)
Thu, Nov 20, 2:23 PM
Unknown Object (File)
Thu, Nov 20, 11:56 AM
Unknown Object (File)
Thu, Nov 20, 11:54 AM
Unknown Object (File)
Thu, Nov 20, 11:50 AM
Subscribers

Details

Reviewers
jrm
Group Reviewers
Ports Committers
Summary

All supported FreeBSD versions either shipped firmware along with
source and do not need this, or they support plain firmware file
loading.

Remove the now obsolete kernel module build code to simplify the
logic in the file. Further cleanup will be done once 13.5-R is
out of support in a few months.

Sponsored by: The FreeBSD Foundation

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 68699
Build 65582: arc lint + arc unit

Event Timeline

bz requested review of this revision.Tue, Nov 11, 1:31 AM
bz created this revision.
net/wifi-firmware-kmod/Makefile.inc
85–87

Given that we are no longer building kernel modules, I wonder if it would be better to take the minor bits we need from Mk/Uses/kmod.mk rather than including the whole file. With USES+=kmod, we, for example, require kernel sources to be available.

If we really need .${OSVERSION} appended to PKGVERSION, you could use _OS_SUFX= .${OSVERSION}.

bz added inline comments.
net/wifi-firmware-kmod/Makefile.inc
85–87

I had planned to leave that for the further cleanup once 13.5-R is out of support, just in case and I did not want to do it all in one go.

I am also still uncertain about the magic being used to recompile certain ports automatically. I need to find the old email if it was purely based on port name including kmod or other heuristics as well. Do we have documentation for this somewhere? I found the old email again: https://lists.freebsd.org/archives/freebsd-ports/2024-December/006997.html Seems we might be good "by name only" but I'll try to confirm this with @bapt before pulling the plug...

So far no one has encountered the issue that modern firmware no longer works on an old release driver; iwlwifi keeps all the files versioned around which made it easy to update and support 3 different releases; realtek, QCA do not do it that straight forward..

net/wifi-firmware-kmod/Makefile.inc
85–87

https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-versions

By appending .${OSVERSION}, an update will be triggered whenever OSVERSION increases because PKGVERSION increases.

% pkg version -t wifi-firmware-iwlwifi-kmod-ax210-20241017.1500049_2 wifi-firmware-iwlwifi-kmod-ax210-20241017.1500050_2
<

It's something that makes sense for kernel modules, but does it make sense for firemware? Do users still need to update their wifi firmware packages when the OSVERSION increases?

Caveat: I'm not certain of all the logic poudriere uses to determine whether a new package should be rebuilt.

  • remove USES+= kmod and comment
  • move BOOT_LOADERCONFD down to the other defines
  • add a comment about mtw (mt7601u) and FreeBSD versions.
  • add a comment in the logic for writing PLIST file
bz marked 2 inline comments as done.Mon, Nov 17, 2:33 PM

I added more revisions to the stack in between for other functionality (rtw88/rtw89 to come) and to fix mtw(4) while here.

I've done successful pourdrier builds against main, stable/15, stable/14, releng/15.0 and releng/14.3 of net/wifi-firmware-kmod .

End of this I must bump the PORTREVISION as not all firmware ports got updated to 202510xx.
But I may also have rtw88 and rtw89 by that time so I am waiting to see what comes first (full review of the stack or more firmware).

This revision is now accepted and ready to land.Mon, Nov 17, 8:46 PM
This revision now requires review to proceed.Mon, Nov 17, 10:19 PM