I wonder when it'll bite us that we implement folio using page and not page using folio...

In D54817#1294097, @kp wrote:

In D54817#1294095, @lwhsu wrote:

Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please everyone.

The current situation and the truth is that people are already using it, and we can't stop them. A strong "NO" will just let some people lie and pretend not using it, or worse, we lost some good contributions.

I simply do not understand this argument. We can indeed not 100% guarantee that no one would commit LLM generated code if we stated an explicit policy against this.
But neither can we guarantee that no one would commit copyright infringing code, but we still have a strong policy against it.

In D39633#1293388, @csjp wrote:

a few years late to the party here but have you tested this?

In D54817#1294095, @lwhsu wrote:

Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please everyone.

The current situation and the truth is that people are already using it, and we can't stop them. A strong "NO" will just let some people lie and pretend not using it, or worse, we lost some good contributions.

Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please anyone.

It looks like @des wrote tests with similar coverage in D55153 and merged them into :main back in February. Taking differential/abandoning revision.

I'll work on getting this over the finish line.

LGTM

use non-breaking spaces for unit sizes, unless we already use a hyphen on that page.

It needs to take the target arch into account.

In D55947#1294047, @emaste wrote:

It seems I had these in my WIP tree as 8 and 9 with a comment LLDB is adding support for sync MTE exception and async MTE reporting.

Snippet from LLDB code:

// SIGSEGV
ADD_SIGCODE(SIGSEGV, 11, SEGV_MAPERR, 1,   "address not mapped to object",
                SignalCodePrintOption::Address);
ADD_SIGCODE(SIGSEGV, 11, SEGV_ACCERR, 2,   "invalid permissions for mapped object",
                SignalCodePrintOption::Address);
ADD_SIGCODE(SIGSEGV, 11, SEGV_PKUERR, 100, "PKU violation",
                SignalCodePrintOption::Address);

So this will be awkward, short term might be x86 PKU violation or arm64 MTE error

See https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/Process/Utility/FreeBSDSignals.cpp

It seems I had these in my WIP tree as 8 and 9 with a comment LLDB is adding support for sync MTE exception and async MTE reporting.

Cool! A couple initial things.

Retract ambitions of O_SYMLINK to O_PATH | O_NOFOLLOW.

Change is good, and I like the commit message.

Updating for ccp.

Hi everyone,

Fix defaults for auto.

If we do the one liner, this is approved in case you don't want to wait for me anymore.

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

! In D54882#1291723, @guest-seuros wrote:
@ziaee , shall we name this driver intelthermal or intel_thermal to mirror acpi_thermal < already in tree ?

In D56507#1293791, @markj wrote:

In D56507#1293342, @rbranco_suse.com wrote:

I succesfully tested the current patch with my suggestions along with https://github.com/freebsd/freebsd-src/pull/2147

Is there any reason not to turn your test program into something we can run as part of the test suite?

missed another spot

missed a spot, thanks bbaovanc!

drop the IEC, it's technically an anachronism, and "binary byte sizes"
isn't any less clear.

I'd say it's fine as is. My one comment verges on nitpicking, so feel free to ignore it.

This matches what Linux does (on all architectures it seems) and will fix aarch64 building with external GCC. Let's go ahead and land this. I think you might want to update the commit log a bit to note the following details:

Thank you for working on this!

I think the text is good enough, but since I am not a native English speaker and I do make mistakes, I would appreciate a review.
Thanks!

If someone had the time to check reports categorization, it would be great. Otherwise, no problem, I will simply proceed to the commit.
Thanks!

@js Thanks for the quick view !

Use copy_to_user

In D56527#1293831, @asomers wrote:

I guess this is ok, even though I normally try to avoid globals if possible. pidfile handling could also be simplified if we forbade changing the pidfile's location during a config reload. Do you think that would be acceptable to do?