I wrote this to look good on a numbered 80x25 console as well as the rendering on phorges with a phone web browser, such as https://ron-dev.freebsd.org/FreeBSD/doc . I have an old one up at https://github.com/concussious/freebsd-doc , but since then I added the bit about sending us pings based on the talk today by @amy.vargas_netapp.com

In D52335#1403900, @uqs wrote:

Can you share why this is being deprecated? Either I'm misunderstanding something here, or this deprecation would make for horrible UX and I'd like to understand what the plan here is and the need to de-support this feature.

In D61234#1404193, @markj wrote:

Where exactly are you allocating pages? Is there some reason you can't just have a dedicated UMA zone which provides buffers for RDMA (or just using mbuf zones), rather than (ab)using vm_page_alloc()?

My initial reaction to this patch is that I'd rather avoid adding complexity to UMA for the benefit of a specific consumer, if it can be avoided.

I will add tests later.

Not thoroughly tested (esp. YP use case).

I don't see the document where it is stated that FreeBSD allow heavy AI assisted contribution, all I hear from other FreeBSD committer is that there is a work in progress document on what is permitted for AI usage.
Until such document is approved and publicly available, any AI contribution should not be merged.
Here it appears that we go the opposite route, aka lets merge the most AI contribution possible until there is a clear official guideline.
This has already happen with port getting at least two dozens of port completely vibe-coded, let's not reproduce it on base until we got a clear guideline from the FreeBSD project that AI usage in base is accepted.

Where exactly are you allocating pages? Is there some reason you can't just have a dedicated UMA zone which provides buffers for RDMA (or just using mbuf zones), rather than (ab)using vm_page_alloc()?

If you tested this patch then commit.
Thanks!

thanks @vvd!

In D61215#1403966, @aokblast wrote:

In D61215#1403613, @kib wrote:

Why do we need this? Is there a function that uses pshared and required to be async signal safe?

If indeed we need this (I doubt), then it is better to use THR_CRITICAL_ENTER() around.

This is found by @markj's AI bot. And yes, we need to be signal safe I think. A signal can contend with process itself over pshared_cache_insert.

Allow site.trust.mk to set rest of sig tuple

Assorted fixes for issues found during testing.
(I was not organized enough to keep them separate.)

games/quake-maps/Makefile:

+DISABLEPAK0=    yes

use vvd's sol'n. I appened the check to the existing ones.

Thanks for sending this in! Let me see if I can find an OG to review this for you.

Maybe something like this:
games/quake-data/Makefile.include:

-.if ${PORTNAME} != data && ${PORTNAME} != maps
+.if ${PORTNAME} != data && !defined(DISABLEPAK0)

The basic idea seems sound to me. I think the patch would benefit from a simple regression test which triggers DAD failure, and then verifies that removal of the original address (eventually) causes the duplicate address to exit the duplicated state. tests/sys/netinet6/ndp.sh is probably a good place to add such a test.

Add security page

Thank goodness you tagged this with docs. It fell though the cracks. However, @des fixed this, so this can be closed.

thanks colin!

Rebase

In D61216#1403883, @wulf wrote:

This looks good, but I didn't verify all the details of clocks and baud generation.

LGTM for the AsiaBSDCon part.

I'm not going to be able to do the netflix testing after all, so go for it. If there's problem, then they can report them on upgrade.

no options needed