On Tue, 9 Dec 2025, John Baldwin wrote:
Hi,
upfront: while talking about this very specific change as well, I really just
want to point out the general problem.
On 12/9/25 15:12, John Baldwin wrote:
The branch main has been updated by jhb:
URL:
https://cgit.FreeBSD.org/src/commit/?id=575639548cef58590a1d70c29e47aae0e8d44153
commit 575639548cef58590a1d70c29e47aae0e8d44153
Author: John Baldwin <[email protected]>
AuthorDate: 2025-12-09 19:59:21 +0000
Commit: John Baldwin <[email protected]>
CommitDate: 2025-12-09 20:00:06 +0000
bus_alloc_resource: Pass rid by value to BUS_ALLOC_RESOURCE DEVMETHOD
The wrapper functions such as bus_alloc_resource_any() still
support
passing the rid by value or pointer, but the underlying implementation
now passes by value.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D53402
FYI, this breaks the build of drm-kmod (hence the __FreeBSD_version bump).
I will open a PR against drm-kmod shortly, but it will still take some time
for the patch to make its way into ports. There's not really a great way
to stage changes that depend on __FreeBSD_version bumps. :(
Yes, it is a pain.
The version check needs to go in for multiple different branches but likely also
needs to be applied to ports via patch file as at least one is based on a tag
and
not on a branch currently for as much as I remember. Just saying as I ran into
all the tiny details with my previous PCI cleanup there, which cost me a delay
of
more than 2 months to get things in (and then still broke nvidia graphics and
networking). Even if not a graphics person, I'll be happy to review this.
That said, I believe, what I had said before, the proper solution [for this
specific case] would have been to implement pci_bus_alloc_resource() in LinuxKPI
and get rid of the FreeBSD specific native code. We already have "drmn"
specific
workaorunds in LinuxKPI due to the special bit of "vgapci" sitting in front of
it.
The infrastructure for that is sadly there but at least it is in one place
under one name.
We would have had to ship that implementation with drm-kmod for older releases
but the problem would have been sorted, and could have been sorted upfront.
We get bitten by unneccesary native code in drm-kmod (and elsewhere) a lot more
these days and every opportunity to clean on up not taken will just bring more
pain later.
I have the next of these "native code in Linux code" problems queued already
for amdgpu but also some in-tree consumers have similar issues (sometimes the
other way round being mostly native but still using some LinuxKPI headers).
/bz
--
Bjoern A. Zeeb r15:7
