Discussion: FreeBSD 14.2-RELEASE Available

It would probably be a lot of wasted effort if the DRM drivers get included in the base with 15. Time that could be better spent on making other improvements.
 
IMHO as a non computer educated person will be "simple" to build drm-kmod for 14.1 and 14.2 packages in this case or in the future (flavor like some apps they have) and problem will be solved.
 
For my part, I'm faced with :


Code: 
cc -target x86_64-unknown-freebsd14.2 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe  -fno-strict-aliasing  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common    -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD  -MF.depend.kern_prot.o -MTkern_prot.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  -std=gnu99 -Werror /usr/src/sys/kern/kern_prot.c
/usr/src/sys/kern/kern_prot.c:828:30: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'int *'; take the address with & [-Wint-conversion]
  828 |                 error = kern_setgroups(td, gidsetsize, groups);
      |                                            ^~~~~~~~~~
      |                                            &
/usr/src/sys/sys/syscallsubr.h:315:44: note: passing argument to parameter 'ngrpp' here
  315 | int     kern_setgroups(struct thread *td, int *ngrpp, gid_t *groups);
      |                                                ^
/usr/src/sys/kern/kern_prot.c:836:1: error: conflicting types for 'kern_setgroups'
  836 | kern_setgroups(struct thread *td, u_int ngrp, gid_t *groups)
      | ^
/usr/src/sys/sys/syscallsubr.h:315:5: note: previous declaration is here
  315 | int     kern_setgroups(struct thread *td, int *ngrpp, gid_t *groups);
      |         ^
/usr/src/sys/kern/kern_prot.c:1310:1: error: conflicting types for 'groupmember'
 1310 | groupmember(gid_t gid, struct ucred *cred)
      | ^
/usr/src/sys/sys/ucred.h:186:6: note: previous declaration is here
  186 | bool    groupmember(gid_t gid, const struct ucred *cred);
      |         ^
/usr/src/sys/kern/kern_prot.c:1331:1: error: conflicting types for 'realgroupmember'
 1331 | realgroupmember(gid_t gid, struct ucred *cred)
      | ^
/usr/src/sys/sys/ucred.h:187:6: note: previous declaration is here
  187 | bool    realgroupmember(gid_t gid, const struct ucred *cred);
      |         ^
/usr/src/sys/kern/kern_prot.c:2367:1: error: conflicting types for 'crsetgroups'
 2367 | crsetgroups(struct ucred *cr, int ngrp, gid_t *groups)
      | ^
/usr/src/sys/sys/ucred.h:172:6: note: previous declaration is here
  172 | void    crsetgroups(struct ucred *cr, int ngrp, const gid_t *groups);
      |         ^
5 errors generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC
      607,85 real       561,73 user        22,58 sys
 
fmc000 said:
Will it even be possible? Is the license compatible with base?
Click to expand...
It is, because it includes the BSD2 Clause and MIT licenses. It uses all of those licenses for the project. If someone forks it, they can use either of those, including exclusively, or a license which those permit, while remaining under those terms.
 
didier Just to verify:
You are building GENERIC from source, not any kind of custom kernel config?
You are not using any custom make config?
Your source tree is up to date?
You are doing a clean kernel build (getting rid of the obj directory)?
You have done a clean "make buildworld" first?

I'm going by old memory (long time since I've updated from source) but those types of errors are usually from partial builds, old builds and are fixed by making sure you start with a clean build environment, up to date sources.
 
sidetone said:
It is, because it includes the BSD2 Clause and MIT licenses. It uses all of those licenses for the project. If someone forks it, they can use either of those, including exclusively, or a license which those permit, while remaining under those terms.
Click to expand...
Are you sure? The DRM code is definitely GPL and lots of files are GPL-only:

Code: 
┬─[fmc000@tu45b-freebsd:~/B/drm-kmod]─[12:52:36]
╰─>$ egrep -ri gpl *|grep -v MIT|grep -i license
drivers/gpu/drm/drm_mipi_dsi.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/scheduler/sched_fence.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/ttm/ttm_module.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_panel.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/i915_live_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/i915_perf_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/mock_gem_device.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/lib_sw_fence.h:/* SPDX-License-Identifier: GPL-2.0-only */
drivers/gpu/drm/i915/i915_module.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/i915/.gitignore:# SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/i915/display/intel_display_trace.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h:/* SPDX-License-Identifier: GPL-2.0+ */
drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/display/drm_display_helper_mod.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/display/drm_hdcp_helper.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_gem_ttm_helper.c:MODULE_LICENSE("GPL");
drivers/gpu/drm/radeon/radeon_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_bridge.c:MODULE_LICENSE("GPL and additional rights");
drivers/dma-buf/sync_file.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/dma-buf/dma-fence-unwrap.c:// SPDX-License-Identifier: GPL-2.0-only
include/drm/drm_gem_ttm_helper.h:/* SPDX-License-Identifier: GPL-2.0-or-later */
linuxkpi/gplv2/include/uapi/linux/sync_file.h:/* SPDX-License-Identifier: GPL-1.0+ WITH Linux-syscall-note */
linuxkpi/gplv2/include/linux/dma-fence-unwrap.h:/* SPDX-License-Identifier: GPL-2.0-only */
┬─[fmc000@tu45b-freebsd:~/B/drm-kmod]─[12:53:01]
╰─>$

Therefore the resulting compiled module must be GPL licensed too.
 
Emrion said:
First, some kernel modules compiled for 14.2-RELEASE (amd64) as installable packages: https://github.com/Emrion/FreeBSD-kmod
Second, don't forget to update your loaders after upgrade: sysutils/loaders-update
Click to expand...
That is a nice little script. Have usually done it manually, but this script saves some effort.

Code: 
root@Testsystem ~# loaders-update show-me
loaders-update v1.0.1
show-me mode: it tells what it would do but changes nothing.

One or more efi partition(s) have been found.

mount -t msdosfs /dev/nda1p1 /mnt
EFI loader /mnt/EFI/BOOT/BOOTX64.efi is up-to-date.
umount /mnt
mount -t msdosfs /dev/nda0p1 /mnt
EFI loader /mnt/EFI/BOOT/BOOTX64.efi is up-to-date.
umount /mnt

-------------------------------
Your current boot method is UEFI.
Boot device: M.2 PCIe SSD-AA230825N4051200411 PciRoot(0x0)/Pci(0x1b,0x4)/Pci(0x0,0x0)/NVMe(0x1,11-04-00-00-00-97-43-a8)
One or more target partition(s) have been found...
All loaders are up-to-date.
-------------------------------
 
fmc000 said:
Are you sure? The DRM code is definitely GPL and lots of files are GPL-only:
Click to expand...
fmc000 said:
~/B/drm-kmod
egrep -ri gpl *|grep -v MIT|grep -i license
Click to expand...
fmc000 said:
Code: 
drivers/gpu/drm/drm_mipi_dsi.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/scheduler/sched_fence.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/ttm/ttm_module.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_panel.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/i915_live_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/i915_perf_selftests.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/mock_gem_device.h:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/i915/selftests/lib_sw_fence.h:/* SPDX-License-Identifier: GPL-2.0-only */
drivers/gpu/drm/i915/i915_module.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/i915/.gitignore:# SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/i915/display/intel_display_trace.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h:/* SPDX-License-Identifier: GPL-2.0+ */
drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/display/drm_display_helper_mod.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/display/drm_hdcp_helper.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_gem_ttm_helper.c:MODULE_LICENSE("GPL");
drivers/gpu/drm/radeon/radeon_drv.c:MODULE_LICENSE("GPL and additional rights");
drivers/gpu/drm/drm_bridge.c:MODULE_LICENSE("GPL and additional rights");
drivers/dma-buf/sync_file.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/dma-buf/dma-fence-unwrap.c:// SPDX-License-Identifier: GPL-2.0-only
include/drm/drm_gem_ttm_helper.h:/* SPDX-License-Identifier: GPL-2.0-or-later */
linuxkpi/gplv2/include/uapi/linux/sync_file.h:/* SPDX-License-Identifier: GPL-1.0+ WITH Linux-syscall-note */
linuxkpi/gplv2/include/linux/dma-fence-unwrap.h:/* SPDX-License-Identifier: GPL-2.0-only */
Click to expand...
fmc000 said:
Therefore the resulting compiled module must be GPL licensed too.
Click to expand...
Usually, when a license in the Makefile has all of them, side by side, it means what I've written, that it uses all licenses, together, side by side by the whole project. In this case, it means the example or code that you wrote. That was a good catch.

They are working on rewriting, thus replacing, essential GPL parts with permissively licensed parts. Parts have been replaced with permissive code. We just have to do with GPL, in the ports tree for DRM, until this happens. Until that happens, it usually stays out of base. It's ok to use it as ports, because we care about functionality for right now, while it would be better for GPL parts to be replaced.

In the past, older versions of the GCC compiler were in base, which these versions were GPL2. GPL parts for GCC utilities might still be in base, because the full toolchain hasn't been replaced yet, while most has with LLVM parts. FreeBSD once relied on older versions, because newer versions of GCC use the GPL3 series, which was considered more restrictive or more unfavorable for FreeBSD's uses.
 
mer said:
didier Just to verify:
You are building GENERIC from source, not any kind of custom kernel config?
You are not using any custom make config?
Click to expand...
A priori, no.
mer said:
Your source tree is up to date?
Click to expand...
I've performed
# freebsd-update upgrade -r 14.2
and followed subsequent instructions.
mer said:
You are doing a clean kernel build (getting rid of the obj directory)?
You have done a clean "make buildworld" first?
Click to expand...
I'm going to check that.
mer said:
I'm going by old memory (long time since I've updated from source) but those types of errors are usually from partial builds, old builds and are fixed by making sure you start with a clean build environment, up to date sources.
Click to expand...
Should be mentionned in the freebsd's manual, should it ?

Anyway, thank you a lot for paying attention of my concern : I feel better.
 
mer said:
I'm assuming you have the src component installed and the freebsd-update command updated it and that's what you are building from?
Click to expand...
Is settingg of /etc/freebsd-update.conf enough for src component updated because on 14.1 I cannot biuild drm-kmod but all others works. Thank you.

Code: 
KEYPRINT=800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5
WORKDIR=/var/db/freebsd-update
SERVERNAME=update.FreeBSD.org
MAILTO=root
ALLOWADD=yes
ALLOWDELETE=yes
KEEPMODIFIEDMETADATA=yes
COMPONENTS=src world kernel
IGNOREPATHS=
UPDATEIFUNMODIFIED=/etc/ /var/ /root/ /.cshrc /.profile
BASEDIR=/
VERBOSELEVEL=stats
TARGETRELEASE=
STRICTCOMPONENTS=no
MERGECHANGES=/etc/ /boot/device.hints
IDSIGNOREPATHS=/usr/share/man/cat /usr/share/man/whatis /var/db/locate.database /var/log
BACKUPKERNEL=yes
BACKUPKERNELDIR=/boot/kernel.old
BACKUPKERNELSYMBOLFILES=no
 
fernandel
I'm taking a guesses here, but I think your setting for COMPONENTS should update the source tree.
But, since the project has moved to git, your local source tree should be a git repo. I think it should live at /usr/src, so you could see what commands like git status tells you.
If you are going across a release with the -r option, I don't know what happens. Is the source tree supposed to be a new branch in a git repo or is it supposed to be "the source tree that matches -r 14.2-RELEASE"? I don't know the answer to that.
Now, building the drm-kmod from a ports tree, I think it mostly needs headers from the kernel source tree, maybe some references during linking.

I would make sure your source trees, kernel/world in /usr/src and ports tree in probably /usr/ports are up to date and you are doing clean builds in the drm-kmod directory.

Hopefully others doing what you are trying will jump in and provide more info.
 
mer said:
fernandel
I'm taking a guesses here, but I think your setting for COMPONENTS should update the source tree.
But, since the project has moved to git, your local source tree should be a git repo. I think it should live at /usr/src, so you could see what commands like git status tells you.
If you are going across a release with the -r option, I don't know what happens. Is the source tree supposed to be a new branch in a git repo or is it supposed to be "the source tree that matches -r 14.2-RELEASE"? I don't know the answer to that.
Now, building the drm-kmod from a ports tree, I think it mostly needs headers from the kernel source tree, maybe some references during linking.

I would make sure your source trees, kernel/world in /usr/src and ports tree in probably /usr/ports are up to date and you are doing clean builds in the drm-kmod directory.

Hopefully others doing what you are trying will jump in and provide more info.
Click to expand...
Thank you.
I do not use git for anything relating to OS. What I use is gitup.
 
I switched to git today and now update the /usr/src via git.
/etc/freebsd-update.conf:
Code: 
Components src world kernel
src - deleted. If I understood correctly. The main thing is not to use both git and freebsd-update simultaneously.
SirDice wrote that to build a drm-kmod you need the source code in /usr/src
 
fernandel said:
Thank you.
I do not use git for anything relating to OS. What I use is gitup.
Click to expand...
I believe "gitup" is a simplification of stand git stuff, specifically the "git pull" command which is used to update a repo. A quick check of "freebsd gitup" it seems to be designed to update a source tree from a git repo but without the overhead of git proper.

I think USerID has the right information about not using git and freebsd-update at the same time, but I think "on the same source tree".
If you want your word/kernel source to live at /usr/src don't do a "git clone" at /usr/src and then try freebsd-update. Put it in different places and you should be fine.

The Handbook and errors: I've not looked in a while not surprised if there is nothing explicit. That may be the assumption of "If you are going to build from source and update from source you are likely smart enough to figure out make clean when you run into errors".
Toss in the drm-kmod rebuild from source because "I updated to next release but pkg is still built against old release" and that assumption if really invalid.
 
mer said:
I believe "gitup" is a simplification of stand git stuff, specifically the "git pull" command which is used to update a repo. A quick check of "freebsd gitup" it seems to be designed to update a source tree from a git repo but without the overhead of git proper.

I think USerID has the right information about not using git and freebsd-update at the same time, but I think "on the same source tree".
If you want your word/kernel source to live at /usr/src don't do a "git clone" at /usr/src and then try freebsd-update. Put it in different places and you should be fine.

The Handbook and errors: I've not looked in a while not surprised if there is nothing explicit. That may be the assumption of "If you are going to build from source and update from source you are likely smart enough to figure out make clean when you run into errors".
Toss in the drm-kmod rebuild from source because "I updated to next release but pkg is still built against old release" and that assumption if really invalid.
Click to expand...
I using gitup ports because I am build few ports still :).
What do you thing to update src with:
pkg add https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_1/FreeBSD-src-sys-14.1.pkg
and see if I can build drm-kmod
 
cracauer@ said:
Warner Losh laid out various ways to get rid of that requirement, but no takers yet.
Click to expand...
cracauer@ said:
Erichans said:
Any link with an overview perhaps?
Click to expand...
Sure.

Click to expand...

It seems a solution for the "kmod problem during the three month overlap"* is in the works, bapt@ committed: kmod: append osversion to the portversion (Dec 10, 2024).

___
* In relation to this problem I posted "3 month package problem" and kmod: append osversion to the portversion (no response there).
 
Erichans said:
It seems a solution for the "kmod problem during the three month overlap"* is in the works, bapt@ committed: kmod: append osversion to the portversion (Dec 10, 2024).
Click to expand...
So, if I understand correctly this commit just change the name of kmod ports.
It remains to do the dedicated repo.

What I don't understand is how pkg can make the transition between old names and new names and how the installed kmods get upgraded after a minor upgrade. I mean, the package names won't be the same, either for transition and minor upgrade.
 
You must log in or register to reply here.
Back
Top