Re: CFT: repository for kernel modules

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

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>