Re: CFT: repository for kernel modules

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>