From nobody Sat Dec 28 02:52:23 2024 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YKn351Xfvz5jn9f; Sat, 28 Dec 2024 02:52:33 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YKn3157sSz4NnY; Sat, 28 Dec 2024 02:52:28 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=dec.sakura.ne.jp header.s=s2405 header.b=VC7E+g7u; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4BS2qNCi040444; Sat, 28 Dec 2024 11:52:24 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1735354344; bh=kjxW3yCjUEQv+Lpkwd8bEdHTa/+Iwrcr8nHDf+/jKu0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VC7E+g7uzv0/YxwsAbT1D1cOaNTlxuYx5QBdbUjeKz5mgs1jEAbm8ye4Df8zacJZy nta7vf3F5ahRvlyaNsIaq30m2yCy1EmRqyAlSTDivYcIZYEjubh2ZGjbggq0dZ6p6S ICfaFLmW8xzVK1x9qmEbIDpu+eO9DRjm0pvarfe0= Date: Sat, 28 Dec 2024 11:52:23 +0900 From: Tomoaki AOKI To: Baptiste Daroussin Cc: Andriy Gapon , Alan Somers , ports@freebsd.org, stable@freebsd.org Subject: Re: CFT: repository for kernel modules Message-Id: <20241228115223.a8bf731f332bbcd2094ae93e@dec.sakura.ne.jp> In-Reply-To: References: <90754854-2a84-4bd8-bc31-dd49296b74c6@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; R_DKIM_REJECT(0.00)[dec.sakura.ne.jp:s=s2405]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org,ports@freebsd.org]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:-] X-Rspamd-Queue-Id: 4YKn3157sSz4NnY X-Spamd-Bar: --- On Thu, 26 Dec 2024 14:23:52 +0100 Baptiste Daroussin 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