Re: CFT: repository for kernel modules
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 01 Aug 2025 11:11:51 UTC
On Fri, 01 Aug 2025 11:26:32 +0200 Zahemszky Gábor <gabor@zahemszky.hu> wrote: > A last question: > > I have an old Nvidia card (Quatro-K4200), which is supported by the > nvidia-driver-470 (and not the official nvidia-driver (-570?)). > Every time the drm-61-kmod binary package changes, it deinstalls > the correct driver and reinstalls the official. Is it possible to handle > it? (Every time I have to type: > > pkg remove -f nvidia-driver && pkg install nvidia-driver-470 > > Are there a more intelligent way? You'll mean graphics/nvidia-drm-61-kmod (as graphics/drm-61-kmod alone does nothing with x11/nvidia-driver nor x11/nvidia-driver-470). So answer assuming the above. None of graphics/nvidia-drm-*-kmod[-devel] supports legacy version of x11/nvidia-driver[-304|-340|-390|-470]. This is because source codes required to build graphics/nvidia-drm-*-kmod[-devel] are NOT contained in legacy versions of drivers, x11/nvidia-driver[-304|-340|-390|-470]. Thus, nothing like graphics/nvidia-drm-61-kmod-470 exists. Also, graphics/nvidia-drm-*-kmod depends on x11/nvidia-driver, and graphics/nvidia-drm-*-kmod-devel depends on x11/nvidia-driver-devel, respectively. And why updates to graphics/drm-61-kmod causes your issue is because graphics/nvidia-drm-61-kmod depends on graphics/drm-61-kmod, too. So upgrade of graphics/nvidia-drm-61-kmod is invoked, thus, x11/nvidia-driver is to be pulled in as one of depeendencies, and conflict with really needed x11/nvidia-driver-470. To bapt@ and any others administrating kmod builder: I've uploaded WIP patch to split kmod parts of x11/nvidia-driver* into corresponding x11/nvidia-kmod* ports. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288314 If you think the concept/strategy acceptable for kmod builders, I'll fix up remaining parts (basically UPDATING entry) and open review for it. Would you look into it and let me know whether it is acceptable or not (hopefully in the PR to keep record about it. Regards. > Thanks, > > ZAHEMSZKY, Gábor > > 2025-07-25 15:14 időpontban Tomoaki AOKI ezt írta: > > On Sat, 28 Dec 2024 11:52:23 +0900 > > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote: > > > >> On Thu, 26 Dec 2024 14:23:52 +0100 > >> Baptiste Daroussin <bapt@freebsd.org> wrote: > >> > >> > On Thu 26 Dec 13:26, Andriy Gapon wrote: > >> > > On 13/12/2024 16:28, Baptiste Daroussin wrote: > >> > > > On Fri 13 Dec 07:24, Alan Somers wrote: > >> > > > > Success! With drm-61-kmod-6.1.92.1402000_3 I can kldload 915kms on > >> > > > > FreeBSD 14.2. Before switching to this repo, kldload would hang. > >> > > > > > >> > > > > Also, in addition to kmods, there are a few other ports that must be > >> > > > > rebuilt for every minor version. devel/py-libzfs is one. Could that > >> > > > > be added to the new repository? > >> > > > > >> > > > Right now and until we have a thin repository support in poudriere: no :(. > >> > > > > >> > > > One of the limitation is everything is cross build from amd64 so I cannot get > >> > > > much things in that repo considering that in 2024 perl is still not cross build > >> > > > friendly and last I checked python wasn't either. > >> > > > >> > > I guess that's also the reason why nvidia driver packages are not built for > >> > > the kmod repo? > >> > > Because they bundle kernel and userland code in the same port? > >> > > >> > Yes ! > >> > It seems they can be easily split, but I don't have the time to split them now. > >> > And I don't have any nvidia device to test > >> > > >> > Bapt > > > > Hi. > > > > Bug 288314 is filed that stating, for 14.3, there are no pkg of > > graphics/nvidia-drm-kmod in FreeBSD-kmods repo. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288314 > > > > Is it a temporary delay? > > > > Or does it (as it is metaport to choose actual nvidia-drm-*-kmod, it > > would be one of graphics/nvidia-drm-*-kmod, though) because of kmod > > parts of x11/nvidia-driver* are NOT splitted from them and > > graphics/nvidia-drm-*-kmod ports are depending on > > x11/nvidia-driver[-devel]? > > > > If so, I'll try to > > *split kmod parts from x11/nvidia-driver[-304|-340|-390|-470|-devel] > > and create corresponding > > x11/nvidia-kmod[-304|-340|-390|-470|-devel], > > > > *let x11/nvidia-driver[-304|-340|-390|-470|-devel] to depend on > > corresponding kmod port, > > > > and > > > > *switch dependency of graphics/nvidia-drm-*-kmod[-devel] from > > x11/nvidia-driver[-devel] to corresponding x11/nvidia-kmod[-devel]. > > > > Note that, other than graphics/nvidia-drm-*-kmod[-devel], > > science/linux-ai-ml-env alone depends on x11/nvidia-driver, > > but it isn't kmod port and would want library parts, thus, > > no plan to modify it (if something is needed to do, it would be > > to allow choosing proper version that support wanted GPU). > > > > TBH, I've already started investigating if it is actually possible > > or not, but not finished. > > > > Any insights and/or thoughts? > > > > > > Another thing to mention. > > All legacy versions of nvidia driver supporting i386 (called x86 > > upstream) are already deprecated upstream. > > > > https://nvidia.custhelp.com/app/answers/detail/a_id/3142 > > > > and dissappeared from top page for Unix drivers. > > > > https://www.nvidia.com/en-us/drivers/unix/ > > > > Actually, any older versions for amd64 (x86_64) can be > > tracked from Archive link. > > > > https://download.nvidia.com/XFree86/FreeBSD-x86_64/ > > > > Fortunately, there is still > > > > https://download.nvidia.com/XFree86/FreeBSD-x86/ > > > > for i386 (just cannot tracked via links) and fetchable. > > But once nvidia decided to delete them, we have no way > > to fetch i386 versions and we cannot know when it is. > > > > I'm planning to send heads-up for the deprecation, > > but still a bit wondering whether we should explicitly > > DEPRECATE legacy versions other than still supported -470 > > or send heads-up alone and remove affected ports once > > it becomes unfetchable. > > > > Anyway, I wouldn't set EXPIRATION_DATE even if DEPRECATE'ing > > affected ports, as when to be unfetchable is unknown. > > > > Regards. > > > > > >> x11/nvidia-driver port is quite complicated with conditionals and > >> reinplaces to support legacy (and unofficially new feature and beta) > >> drivers. (x11/nvidia-driver is the master port of x11/nvidia-driver-* > >> having all required supports/workarounds per-version differences). > >> > >> And it strongly depends on bundled pre-compiled (proprietary) large > >> blobs, so possibly even splitting it into kmod parts and libraries > >> part > >> would not help cross compiling. > >> > >> And more, graphics/nvidia-drm-[510|515|61]-kmod depends on it and > >> corresponding graphics/drm-[510|515|61]-kmod ports, could make it more > >> complicated. > >> > >> But one possibly good news would be that native i386 is terminated on > >> newer than 390 branch of drivers, and chasing Xorg ABI changes like at > >> 1.20 for legacy drivers are not 100% promised. > >> > >> > >> https://forums.developer.nvidia.com/t/x-wont-start-on-xorg-server-1-20-and-nvidia-legacy-390-new-abi/61219 > >> > >> > >> https://forums.developer.nvidia.com/t/unix-graphics-feature-deprecation-schedule/60588 > >> > >> So once the Xorg ABI changes again, nvidia decides to chase it only > >> on production, new feature and beta branches at the moment and xorg > >> related ports on FreeBSD switches to newer version, we can (forcibly) > >> drop supports for legacy drivers supporting i386. > >> > >> *Running 32bit i386 apps on compat supports of amd64 OS is still > >> supported at least currently. > >> > >> And, Ugh, should we consider using --kernel-module-type=proprietary > >> option for x11/linux-nvidia-libs depending on its version (560 and > >> later only)? > >> My current assumption is that what affected by this are kernel modules > >> only and other components x11/linux-nvidia-libs installs are not > >> affected. But I'm not a nvidia insider and cannot be sure. > >> > >> Anyway, currently we give "--extract-only" flag to *.run in > >> x11/linux-nvidia-libs/Makefile, so anything required to be run for > >> detecting GPU to choose module flavor (proprietary or open) shouldn't > >> work here. > >> > >> -- > >> Tomoaki AOKI <junchoon@dec.sakura.ne.jp> -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>