Looks good with one additional minor fix

Newer virtio has been implemented in Illumos https://www.illumos.org/issues/17767

Pedantically the non-repro output is in both uname(1) and uname(3), but I think this is fine.

Will push after stabweek concludes

I think citing rfc4291 section 2.5.2 for the commit message would then make us consider removing this alltogether?

Does it make sense for FreeBSD to adopt the repo and maintain the component upstream like that :/?

In D54895#1255113, @minsoochoo0122_proton.me wrote:

Okay, I'll backport to our tree after Dimitry finishes his llvm import. But since it's unclear how upstream would respond as well as the progress on importing llvm 21, I think it would be better to review this now and bring -w change later.

Thanks, I will push after stabweek concludes.

Two open pull requests:
https://github.com/google/capsicum-test/pull/35 - Fix OpenatTest.WithFlag when O_BENEATH is passed after 5eb909a37339fe4675ef95b769a07c5eb3894799
https://github.com/google/capsicum-test/pull/40 - Separate out differing O_BENEATH behaviours
Three open issues:
https://github.com/google/capsicum-test/issues/27 - OpenatTest.* failures if vfs.lookup_cap_dotdot is disabled
https://github.com/google/capsicum-test/issues/28 - OpenatTest.WithFlag / ForkedOpenatTest_WithFlagInCapabilityMode._ fail fails on FreeBSD
https://github.com/google/capsicum-test/issues/60 - sctp.cc's #ifdef HAVE_SCTP is not functional on FreeBSD

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

-w opens /dev/mem RW; without -w attempts to write will fail.

To expand on my comment - the reason I think it's worth mentioning that is to make it clear we haven't made a choice to ignore this tunable with UEFI, it's that it just doesn't apply with UEFI.

It's not so much that it's ignored, but UEFI boot does not use vga mode so the hw.vga tunables don't do anything. Maybe something like "Because UEFI boot does not use VGA mode, ..."?

But I also have one more question: one of the warnings is also about unexisting .Xr sysctl 2. As I can see, there is no sysctl(2) in FreeBSD, only sysctl(3). But the man pages talks about it in the context of syscalls, so it seems that we can't just change sysctl(2) to sysctl(3) since sysctl(3) is not a syscall. What sould we do about that?

It will go together with the rest of the eventfd-related patches once they are all approved. Otherwise it’s not very useful alone, at least in the context of DRM drivers.

OK to go ahead with this?

OK with me

On the one hand we should be able to just bring along the necessary libraries for LLVM tools in whatever use case we have. On the other hand this is a simple and straightforward change to fix this case, which needs to work so fine with me.

Why do we use linuxkpi prefix sometimes and lkpi others?

IMO it's worth putting all of that in the commit message -- that this came from CHERI and why, but also it's just generally better.

What do we expect to do with the remaining patches in this stack?

There is also reference HFI source code from Intel available at https://github.com/intel/intel_hfi

I had this in D48244 as well. @mat didn't like it and @cperciva pointed out that it can be a useful quick reference for finding out when something was implemented or changed.

I want to make sure all the issues are fixed there before anything gets MFCed.

Linux does seem to read these registers in a few places, but it's hard to see whether the bug is likely to cause problems.

It doesn't seem so, at least in FreeBSD. The only read of these registers I found is in arm_gic_db_show().

There's the same assertion earlier in the fn for the ts allocation.

Does nothing actually care about the return value today?

we aren't making any more assumptions in this change

I wonder if we want to add some validity checking on ph->p_memsz while we're here? I think a wrong p_memsz will be handled the same before/after this change so it's fine from that perspective, it's more general pondering about what if any validation rtld ought to do.

This seems reasonable to me

I think it's worth adding a comment as well -- https://reviews.llvm.org is deprecated and this review is never going to be updated or completed. I'm not sure if @dchagin or @arichardson have a rebased version of it but someone will need to pick it up.

Committed as dac74b20c706b1f73986fb40dac27ed85c1d2850

Yes let's push this into main and iterate on it from there if necessary

This needs a description for WITHOUT_SOUND in tools/build/options