In D42763#1001148, @emaste wrote:

In D42763#975454, @cperciva wrote:

In any case, the hard-coding was a "make sure we don't end up with every binary on the system being modified if someone screws with param.h" seat belt.

But we end up with a subtly-broken (inconsistent) system in that case - we should implement such a seatbelt as a commit hook instead.

Makes sense to me.

LGTM.

LGTM. Thanks for taking care of this!

In D40403#931222, @markj wrote:

In D40403#930878, @cperciva wrote:

@markj Is this waiting for anything else before it lands?

I am not sure it's a good idea to land the patch right before stable/14 is created. I've done a fair bit of testing locally but there's lots of potential here for bugs/races which are specific to a certain platform. Since such bugs might take a while to flesh out, I'd prefer to wait until after the branch is created.

Just to confirm, this will land in stable/13 and stable/14? It looks like we have the gve driver in both.

I haven't read the PCI spec, but this works on the m7i.2xlarge instance I was testing with, and seems to match what Linux does:

Can you add something to the commit message about the #ifdef RSS going away?

Yep the URL is deliberately 404. I just sent a draft out to developers@ but I'm leaving a bit of time for feedback before I put it on the website.

Update per pauamma.

LGTM aside from maybe the word "uncommitted".

I have a vague recollection that we made this change because at one point __FreeBSD_version *did* change on an errata branch. Possibly when an OpenSSL update was merged?

The title on this is "ena: Update the license dating to 2023" but it looks like it's doing far more than just updating the year?

LGTM, please commit.

On my Framework laptop (where I was running recent tests and posting on twitter), this shaves off about 0.7 seconds of boot time and 333 processes. But that's under 20% of the time spent in devd so there's still more investigation to be done.

Already done: https://cgit.freebsd.org/src/commit/?id=a959ae1c503d104f1e28033522362e5054f52c94

Since nobody seems to be responding to the github PR, should I just commit this to FreeBSD? We need it in ASAP for the release...

https://github.com/openzfs/zfs/pull/15405

@allanjude Right, I wasn't sure what the usual process was with OpenZFS. Should I commit this to FreeBSD first and then open a PR at https://github.com/openzfs/zfs/ ?

LGTM

Looks correct to me.

This is a bit orthogonal to the change I made. I removed the option to build the entire FreeBSD tree without Capsicum, but there could conceivably be a desire to build bhyve without Capsicum. (For example, I think the snapshot code needed Capsicum to be disabled for a while.)

I garbage collected the AZURE_DISK variable since it was unused. (Note that CLOUDWARE does not include AZURE so in fact *none* of the cloudware-related AZURE variables are used, but _DISK in particular isn't used for any of the cloudwares.)