Re: CFT: repository for kernel modules

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?

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>