x11/nvidia-driver: Splitting out kmod part of x11/nvidia-driver into x11/nvidia-kmod, including slave ports.

[junchoon_dec.sakura.ne.jp]

Summary

Split out kmod part of x11/nvidia-driver into x11/nvidia-kmod,
including slave ports, to allow FreeBSD-kmods repo builders building
nvidia-related kmod ports.

In this update,

*split out *.ko from x11/nvidia-driver[-304|-340|-390|470|-devel]
 into corresponding x11/nvidia-kmod[-304|-340|-390|470|-devel],

*switch dependency of graphics/nvidia-drm-*-kmod upon
 x11/nvidia-driver[-devel] to newly introduced
 x11/nvidia-kmod[-devel],

*make x11/nvidia-driver[-304|-340|-390|470|-devel] depend upon
 newly introduced x11/nvidia-kmod[-304|-340|-390|470|-devel],

*bump consumers directly depending upon x11/nvidia-driver*
 as of dependency switches,

*and hook x11/nvidia-kmod[-304|-340|-390|470|-devel] to build.

Note that upgrading x11/nvidia-driver* from monolithic version
requires deinstallation of x11/nvidia-driver* before starting,
as both previous version of x11/nvidia-driver* and newly introduced
x11/nvidia-kmod* installs *.ko into same place.

PR: 288314

[junchoon_dec.sakura.ne.jp]

Should I include UPDATING part into this, or opening separate review is wanted?

TBH, UPDATING part is already uploaded to Bug 288314, but should need fixing date on commit,
unlike other parts here. So you can obtain UPDATING (currently for main branch only) part from the PR,
without opening independent review or updating this review.

[ziaee]

Why?

[junchoon_dec.sakura.ne.jp]

For which context? This review itselr? Or for treatment about UPDATING?

If the former, it is because there's currently no pkg in the FreeBSD-kmods repo.

https://lists.freebsd.org/archives/freebsd-ports/2024-December/007070.html

For why UPDATING entry is needed, as described at the end of summary, if x11/nvidia-driver* is already installed, x11/nvidia-kmod* cannot be installed because of "actual" conflicts with *.ko and x11/nvidia-driver* need to be deinstalled first and freshly installed again (it would sanely pull in corresponding x11/nvidia-kmod* as the dependency).

And why I'm wondering whether UPDATING should be included in this or not is that UPDATING needs to be fixed up the entry's date on land with the day actually committed, and I'm NOT a committer, so I cannot fix up by myself.

[junchoon_dec.sakura.ne.jp]

Opened another review to upgrade to 580.82.07 as D52352, which is the latest Production Branch of drivers.

I'll rebase this review if D52352 lands earlier than this.
On the other hand, if this lands earlier, I'll rebase D52352.

[junchoon_dec.sakura.ne.jp]

Rebase for upgrading to 580.82.07 at commit ports 2b2519a398fa84d21af69c8dc88c25f92aaa2d5f.

Added missingly lost PORTREVISION bump for graphics/nvidia-drm-kmod on previous patch. This should be needed as of additional dependency onto x11/nvidia-driver[-devel].

[junchoon_dec.sakura.ne.jp]

Found new Production Branch of driver set 580.82.09 upstream.
Should I update ports for it? If so, patch in this review would need rebasing.

If it hurts ongoing (I hope so) test, I'll hold updating current form of ports until this review is accepted and landed (or rejectet).

Anyway, the new version seems to be a minor bugfix that limited users are affected, and updates for ports is trivial.

https://www.nvidia.com/en-us/drivers/details/254127/

https://www.nvidia.com/en-us/drivers/details/254126/

So this review would be far more urgent for average users that want nvidia driver sets in kmod repo.
TBH, patch for current form of ports is ready and remaining work for rebased patch of this review is just to generate clean diff. The driver set is running as usual for my Quadro P1000 (notebook).

[arrowd]

x11/nvidia-kmod/Makefile

37

Won't splitting the distinfo across the slave ports be actually cleaner? I remember nvidia ports were having problems with regenerating the distinfo.

[junchoon_dec.sakura.ne.jp]

x11/nvidia-kmod/Makefile

37

What made distinfo hard to update was that x11/nvidia-driver/distinfo contained all distinfo for all slave ports before commit 9506d5a4e7134abd57d5d001edb1a092c11d1291.

The reason of difficulties are because of "race conditions across PRs for different master / slave ports", as all required to modify exactly same x11/nvidia-driver/distinfo prior to the above-mentioned commit.

Now it is splitted into per-slave-port basis and things are far more cleaner. For master, -470 and -devel, simple make makesum in each directory is sufficient now.

And yes, there remains difficulties for 3xx versions of legacy drivers, which support both amd64 and i386.
But as 3xx branches of driver packages are already EoL'ed by upstream at the end of 2022, and unlikely to be updated anymore.

https://nvidia.custhelp.com/app/answers/detail/a_id/3142

Why I'm keeping 3xx branches of legacy versions is because the upstream tarballs are still fetchable and users of i386 and/or of old GPUs would want it as long as possible.
So I'll file a PR and open review for 3xx branches once I've confirm they are no longer fetchable. But it's not now, fortunately.

[junchoon_dec.sakura.ne.jp]

As graphics/drm-[61|66]-kmod are updated and corresponding graphics/nvidia-drm-[61|66]-kmod[-devel] are bumped, this need to be rebased to land sanely.

But unfortunately, updates of graphics/drm-[61|66]-kmod broke graphics/nvidia-drm-[61|66]-kmod[-devel] as of their internal changes of how to obtain PCI device info from FreeBSD generic to DRM specific.

This is to be fixed once patch at Bug289647 lands.

So will rebase after it lands and graphics/nvidia-drm-[61|66]-kmod[-devel] starts working again.

The rebased patch wouldn't contain upgrade for nvidia driver package to 580.82.09 to get this landed earlier.

[junchoon_dec.sakura.ne.jp]

Rebase after commit ports 971606f3493fbbc77c156ab84243ab952d89a81b.

Now includes UPDATING. Please update the entry date on commit.
No other changes intended.

[junchoon_dec.sakura.ne.jp]

Can this be committed before new quarterly 2025Q4 is branched so that upcoming pre-built pkgs for 15.0-Release surely have this at its beginning?

[junchoon_dec.sakura.ne.jp]

Thanks!