It looks like <= PAGE_SIZE would indeed be correct

A redeclaration of an entity without a linkage specification inherits the language linkage of the entity and its type (if exists).

From the Jails Production User call: This work is still of interest, particularly in the context of OCI jail progress.
DCH: "This needs serious rebasing." Do any developers have interest in this feature?

Thank you both for the quick response.

On my slightly older current: [current-D49403_iwlwifi_fw_update] [2025-03-18_16h39m38s] [committing] Queued: 34 Built: 34 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:03:25

Abandoning this differential. New differential follows.

Running a mini (Queued: 2012) exp-run with this Diff.

• Apply suggestions

As with any other patches of the kind you may either fix the "issue" or break sound completely by producing invalid configuration. Unless the configuration is already broken and require fixing, it should better be handled with /dev/dsp redirection, as we discussed before.

Hmm, my assumption is that the extern "C" for the prototype is sufficient for the compiler to use the "C" symbol for the function when compiling conf.cc, but that permits using C++ constructs in conf.cc. In the future these methods in conf.cc will be invoking methods on C++ objects so it needs to be a conf.cc file, just that the symbols exported from it use C symbol names (not mangled).

In D49138#1126519, @jhb wrote:

In D49138#1126074, @imp wrote:

This is a common pattern in CAM to make things more debuggable.

Why #define rather than done variation on const int foo = 0x1000; ?

Oh, I just did #define since that is the most common way of doing constants in the tree. I would not be opposed to using const int.

In D49138#1126074, @imp wrote:

This is a common pattern in CAM to make things more debuggable.

Why #define rather than done variation on const int foo = 0x1000; ?

.. and whilst i'm at it, I can /also/ talk about the original atheros AR5210 NIC, which yes is old, but I /can/ super duper give it as an example.

In D49393#1126451, @bz wrote:

Your description for the commit message is very misleading (*); I read it thrice in the hope to understand what you mean. Trying to paraphrase:

Reject a key for a cipher suite [forcefully (given it is not announced as supported)] set by user space (i.e., wpa_supplicant) although it is not set as supported in software crypto or device driver hardware crypto at all.

Which makes me wonder: I do not believe that we can do any hardware crypto without any software support so the code for setting ic_cryptocaps should enforce that the crypto suite is also set in ic_sw_cryptocaps (that implies an order of setting -- or given we have a default rely on that). Also the code for setting ic_sw_cryptocaps should check that we actually have an implementation ...

• Tidy up headers
• Split out debug.h
• Fix build without debug
• Manage firmware lifetimes better
• Change probe priority

I do like std.wifi for the stack. Not for the drivers which are their own problem.

Wifi is kinda a special case. We have multiple drivers for the same hardware that play badly together because linuxkpi driver bidding model sucks.

Merged.

In D49359#1126495, @zlei wrote:

In D49359#1126467, @franco_opnsense.org wrote:

For 285129 this still crashes in the same place: https://github.com/opnsense/src/issues/207#issuecomment-2733080313

Is that based on stable/14 ?

In D49343#1126494, @adrian wrote:

Yeah, creating a std.wifi would be good, especially for the options versus the stack and drivers.

I'll pencil that in for a refactor after all of this lands.

Thanks for the suggestion/idea! Honestly it's been bugging me for years too.

In D49359#1126467, @franco_opnsense.org wrote:

For 285129 this still crashes in the same place: https://github.com/opnsense/src/issues/207#issuecomment-2733080313

Yeah, creating a std.wifi would be good, especially for the options versus the stack and drivers.

Superseded by aaf0a7302d10.

Superseded by c0bed9bd0bda.

Superseded by c0bed9bd0bda.

Superseded by c0bed9bd0bda .

I don't know who represents maintainer apache@FreeBSD.org, but I guess I have to give the potential maintainers two weeks of time for this.

@jrm, yes of course, it simply worked in poudriere. Did forget to bump the revision.

If this changes the package, please bump PORTREVISION.

For 285129 this still crashes in the same place: https://github.com/opnsense/src/issues/207#issuecomment-2733080313

https://ci.freebsd.org is currently down; I'll take a look soon