This is sort of WIP - there's some TODOs in here. I'd like some feedback on the locking changes and whether I missed something. Thanks!

Does this have anything to do with Rust ports specifically? This review is tied to the deprecation of the --ar flag in Rust (which is documented to do nothing).

ofwfb needs the following properties to work correctly:

Well, folks that do not use poudriere(-devel) have been locally putting back ar=${AR} in some places so that their make/Makefile or portmaster style of working can find the right ar. An example is:

Fixed the space typo. Thanks for the patience.

Remove templates.

FWIW, openjdk21 and openjdk22 build fine on i386 14.3-RELEASE. https://pkg.ftfl.ca/build.html?mastername=143i386-default&build=2026-01-28_17h04m33s

Merged to :main as rG46333229c6a0187ebf231805682ee0bceed704d1.

Make a no-op so it is MFCable

For MFC purposes, I think I will change this to use BUS_PRIVATE_IVARS + 1 for the buses that currently start at 1 and insert a commit to renumber those. That would let me MFC this change at least.

FWIW this simple .export OBJTOP works ok for buildworld but not for targets like universe where multiple arches try to use the same OBJTOP which quickly ends in tears.
The more elaborate patch in https://reviews.freebsd.org/D54819 blows up in buildworld due to being incompatible with assumptions made by all the *compat* bits, but once that compat stuff is fixed, probably has a hope of working for universe too.

This looks good to me modulo one style nit I can fix while merging. Is "Marcin Cieslak <saper@saper.info>" the right way to credit you as the author of the commit?

I think changing sysctl_handle_bool directly is fine.

You definitely don't want '-w' by default as it is quite dangerous, but it can be useful on a live system to be able to modify variables in the kernel, and it does mean passing O_RDWR to kvm_open().

Also, you can't do this this way. You have to bump the symbol versions of all symbols that create a FILE object that uses _fileno, and in the old compat version, still limit to 16-bit descriptors because that old software is using the old fileno() macro that reads the file descriptor from the old location. Only in the "new" versions of functions like fopen(), etc. can you actually use the wider fileno field.

I don't think renaming the field does any good here. This isn't the field that existing software accesses directly, and all the software that does is using fileno() which is already part of the API and exposes the ABI.

Oh, this is the sort of thing I really hoped to avoid, was exposing all of FILE as a new ABI. I was careful in my previous versions to figure out which parts of FILE were actually used (not _fileno which doesn't matter, but all the _other_ fields that things like gnulib abuse) and then tried to make FILE mostly opaque, and added the wider _fileno in a slot that was safe to reuse that was near the front still. I think I also used some #ifdef's to ensure that only the fields in FILE that were part of the public ABI were exposed outside of libc. This doesn't do any of that.

I'll use the momentum. Would it make sense to add something like this to sys/kern and only driver it from LinuxKPI so it could be used for something else as well?

In D53862#1256007, @jhb wrote:

This looks good to me btw.

This looks good to me btw.

In D52581#1255918, @cperciva wrote:

In D52581#1255798, @bz wrote:

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

If this commit reaches releng/14.4, at that point it would point to release_4 and kmods_release_4, which would be copies of quarterly and kmods_quarterly_4 made at the appropriate time. So we're talking about packages built from the quarterly (in this case 2026Q1) branch of the ports tree; the difference between the "kmod" repo and the non-kmod repo is that the kmod repo only has kmod packages and is built with a newer src tree.

This really shouldn't be needed as drivers like iicsmb and i4giic should create child smbusX devices, and when those devices invoke bus_identify_children that should call the identify routine and voila.

The magic of vn_open_cred() is probably not something that will go away.

Does this mean all TB3 support will be removed? Is there more to cleanup in that case?

Regardless, adding another note to an existing entry in the description seems fine to me.

Hmmm, I tend to use the commit that actually bumped the value as the gitref FWIW. You could try building the website locally (need docproj installed and then you can cd documentation ; make run. After several minutes it will then give you a URL on your localhost you can point a browser at to read the updated docs.

use the macro M_HASHTYPE_CLEAR instead, no functional change

Whitespace fix

Added the comment code, updated the function description in the manpage
instead of an error code.

Looks good on 16-CURRENT amd64. https://pkg.ftfl.ca/build.html?mastername=16amd64-default&build=2026-01-28_15h06m03s

I used the code logic from install(1).