Ping.

Ping.

Ping.

Thanks for the heads up I'll update those too.

I see the code of this driver the first time, but incrementing IFCOUNTER_OERRORS everywhere where tx_dropped is incremented makes sense. The positions of the lines where the other IFCOUNTER_* counters are incremented seems correct to me as well.

@jrm Awesome! Thanks!

One thing that I'm unsure about is the need to migrate /usr/local/etc/mysql/my.cnf to /usr/local/${SERVER}/etc/mysql/my.cnf. While I mention this in UPDATING it still feels like there is a high chance that end users would just do pkg upgrade without reading anything.

this is very simple how the kmods are built:
kmods are built for every arches, every release (and stable)
FreeBSD:X:arch/kmods_quarterly are the kmods from the quarterly ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo which are always published in a predictable manner)
FreeBSD:X:arch/kmods_latest are the kmods from the main ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo)
FreeBSD:X:arch/kmods_quarterly_Y are the kmods from the quarterly ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)
FreeBSD:X:arch/kmods_latest_Y are the kmods from the main ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)

In D54619#1256076, @markmi_dsl-only.net wrote:

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:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292544

for which the original editing for the original problem also had an ar=${AR} removal. Some folks then reported build errors tied to ar commands that failed to recognize command line syntax used during the port build --and later reported that putting back the ar=${AR} got things to build again for them.

Has make/Makefile or portmaster based build testing been done for this context?

Note: I use poudriere-devel .

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.