This patch was superseded by the refactoring of D50849 and D50850.

@bz: Do you have any remaining objections to this patch?

In D54275#1240636, @jhb wrote:

Maybe to make it clearer we can change the struct to use a union of next_seqno and initial_seqno which won't change the ABI but will let us document it in the header and be more clear about the intent?

added union for next_seqno / initial offload seqno to provide a better description & preserve ABI, as suggested by @jhb

Also, on Linux, struct eventfd_ctx is defined privately in fs/eventfd.c. The struct fields are never accessed by consumers of the eventfd API.

In D54268#1240309, @markj wrote:

In D54268#1240216, @alc wrote:

Since we are starting to expand the usage of vmem, I want to point out something that I only noticed around the time we added support for nextfit allocation. What we call bestfit is really an implementation of firstfit allocation. (A comment pointing this out was actually deleted from the Netbsd original when vmem was imported.) And, what we call firstfit is what, I believe, Solaris calls instantfit. We have no actual implementation of bestfit allocation. That said, mav's long ago change to "create own free list for each of the first 32 possible allocation sizes" has the effect of bestfit allocation for small sizes.

Here is the comment that got deleted:

	} else { /* VM_BESTFIT */
		/*
		 * we assume that, for space efficiency, it's better to
		 * allocate from a smaller block.  thus we will start searching
		 * from the lower-order list than VM_INSTANTFIT.
		 * however, don't bother to find the smallest block in a free
		 * list because the list can be very long.  we can revisit it
		 * if/when it turns out to be a problem.

If I understand correctly, libuvmem was motivated by a need for an address space allocator for PCI BARs in bhyve. I think a proper M_BESTFIT probably isn't required there, but it might be good to implement one nonetheless. As a first step, perhaps we should restore the naming from Solaris.

Move INSTALLEXTRAKERNELS after NO_INSTALLEXTRAKERNELS is set. Hidden by testing originally on CheriBSD where we set NO_INSTALLEXTRAKERNELS to no early for Morello..

Can we put this in build(7)?

D54291

In D54282#1240666, @jrtc27 wrote:

I can make NO_INSTALLKERNEL less gross if that would help?

In D54282#1240665, @ivy wrote:

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

Maybe start with enabling the module for arm64 ?
It's unlikely that anyone will test adding the driver to their kernel config if they didn't tested with the module before.
Also I don't see why anyone would want the driver in the kernel if a module exists.

Maybe to make it clearer we can change the struct to use a union of next_seqno and initial_seqno which won't change the ABI but will let us document it in the header and be more clear about the intent?

switch examples consistently to /client, thanks @fuz!

pair down, thanks so much everyone

I don't care how it's fixed, but I will commit this pretty soon if a broader fix isn't added. The linuxkpi fix should never have been committed without a fallback.

Des says I need to change everything all at once. It will take a while, but I think this is the correct direction to move in, so I will do this.

+ "Upgrading from Distributions" -> "Upgrading from Distribution Sets"
+ Adjust "Upgrading from Source" language

Hi pkgbase people! We need good instructions in the "Upgrading from Packages" section of the release note. If you know how to upgrade a pkgbase system to 15.0, help^W now is your time to shine!

By the way, I only took a moment to search for "releng" in /usr/src/UPDATING, but didn't get a hit.

The commit mentioned refers to this: https://github.com/freebsd/freebsd-src/pull/1905