Is this actually KBI or just internal KBI between kernel and vmm, which would always be in sync?

virtio_blk calls bus_dma_tag_set_iommu on PowerPC; would that not be needed for these new tags?

Do we still need the mb()s? I would expect bus_dmamap_sync to suffice.

IIRC GNU as and LLVM IAS disagree on what .weak and .glob[a]l mean. LLVM IAS doesn't let you mix them, but that's not really sensible, since one is binding and the other is visibility. We use .weak for linker sets but not .glob[a]l (I think used to use both) because one version of LLVM introduced that error, whilst I think GNU as wants what we used to have where we put both. I should probably raise it with upstream LLVM to point out that what they did doesn't make sense.

In D54964#1256922, @jhb wrote:

In D54964#1256826, @markj wrote:

In D54964#1256808, @jhb wrote:

I tried using a constraint of "m" and an operand modifier of "a" which I think is more what we want anyway (if you remove the & in the operand), but that gives me ICEs in both GCC 14 and GCC 15. This whole thing seems a bit gross. I realize we want the real symbol here and don't want it to resolve to 'foo@plt' or the like, but this whole thing feels a bit clunky. I guess we can't just do _SDT_ASM_WORD _SDT_PROBE_NAME(...) directly?

Sadly no. This doesn't work for function-scoped static variables, since there the variable name is not equal to that of the emitted symbol. And the DTRACE_PROBE* macros defined in sdt.h (and I think only used by ZFS) need this to work.

(Presumably on CHERI _SDT_WORD here is a .chericap and would really need the symbol name and not some goofy "make the compiler generate a constant address" thing anyway?

It expands to .chericap "%c0" with the operand defined as "i" (__unbounded_addressof(_SDT_PROBE_NAME(...)).

Humm, what what does the %c0 expand to? You can't really do .chericap 0x12345 and have it be meaningful at all. It has to be a symbol so that the assembler emits a static relocation that the linker can use to figure out the right bounds and permissions so it can construct a suitable relocation (either a .caprelocs / R_MORELLO_RELATIVE for a non-preemptible symbol, or a R_CHERI_CAPABILITY).

Ping? I went to update my board last night and noticed I still had this (with my inline suggested fix) as a local patch.

In D54969#1256900, @mhorne wrote:

Thanks a lot for handling this.

As I recall from previous experiments building with GCC, there was some missing atomic libcall, or something? Maybe this has resolved itself?

In D54966#1256752, @bz wrote:

In D54966#1256747, @jhb wrote:

I have no idea why clang fails to warn about this as I noted in the commit log. OTOH, if we want to make '%#b' a real thing, we need to document it in the manpage and fix both compilers to intentionally (vs accidentally) accept it.

I thought someone else was working on more %b for FreeBSD; or at least 64bit %b argument support. Was it @tuexen? I'd be happy to %#b supported :)

Effort: CHERI upstreaming or whatever it is seems like it would apply?

In D54246#1254644, @kib wrote:

In D54246#1254643, @adrian wrote:

ok, but on insistence from jrtc27 i added some debug logging here and it's never actually invoking syncicache in my tests.

This does not mean much. It only shows that the current binaries do not have this issue. But old binaries might have, then removing the hack breaks them.

In D54246#1254603, @adrian wrote:

This works for me on freebsd-16 on power8, I'm doing test buildworld -j32 on it right now!

In D54857#1254516, @doonbsd_gmail.com wrote:

Hold on. I just found one style problem. There must be a empty line after start curly brace when the function has single line body.

I send an updated patch.

In D54876#1254502, @imp wrote:

What are you using this for? I think it's ahoodchange, but I'm curios.

Well it is where it is because (a) asserting in vmmops_init is pointless with M_WAITOK as you say (b) vm_init is in a separate translation unit so in some world views should treat vmmops_init as a black box, and is therefore asserting that it never fails. And this pattern is copied from arm64, so we should keep the two consistent, whichever way it goes.

https://reviews.freebsd.org/P685 is a proposal for how to drastically reduce the amount of boilerplate here (even compared with the ifunc-only version). The wrapper vs ifunc difference is mostly hidden, with the only way it leaks out being that the macro needs to take argument types and names separately so it can use just the names in the call for the wrapper variant. That could be simplified back down in a future ifunc-only version. Built and test-booted arm64 GENERIC and riscv64 QEMU (with other patches to deal with the other issues here).

In D54831#1253758, @kib wrote:

In D54831#1253740, @jrtc27 wrote:

armv7 and riscv64 are tier 2, breaking them is not permitted. I have an idea for how to make them work though, without being too invasive.

ifunc can be emulated with the function pointer. This is of course breaks the microoptimizations real ifunc provides, but should keep the arches going until maintainers finally implement the proper solution.
I do not want to code that.

armv7 and riscv64 are tier 2, breaking them is not permitted. I have an idea for how to make them work though, without being too invasive.

Do we need to worry about $s in OBJROOT?

This probably needs more of an explanation for the issue with this pattern on CHERI than we had downstream

Our pkg is old enough to predate that support, but we're also not doing pkgbase yet, so presumably once it's mature enough upstream for us to adopt it downstream we'll first update pkg.

Won’t that break the dependencies list if clang is itself 32-bit? This also introduces a new hard-coding of the set of compat libraries rather than using _ALL_libcompats.

the "extint-gpio1" check returned NULL

In D54757#1251288, @aokblast wrote:

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken

Sorry, the commit message is not clear. I try to explain with more detail. Please tell me if you need anymore information.

When

pwd == $OBJTOP

, and after

run rm -rf "$OBJTOP"

getcwd(3) will return with error since the directory is deleted.

Under this condition:

When shell is executing:

mkdir -p "$OBJTOP"

bear intercepts the libc exec(3) function call and call getcwd in here. As a result, it causes an error.

I don’t understand, other than it sounding like bear is broken

Switching from name ## _baseclasses to basevar ## _baseclasses to avoid the gross #defines you removed seems worthwhile, but I don't see the point of the churn for the rest. Especially since deprecating something that is the only thing being used is a foolish thing to do.

Inline them? There are only 5 calls in total.

Another minor issue is visual distinction between elements. The same colour and text styling (when not hovered over) are used for headings and links here:

In D53910#1245581, @mark_freebsdfoundation.org wrote:

In D53910#1241780, @jrtc27 wrote:

Just looking at the homepage there is some very strange use of whitespace: specifically, there is a lot of extra vertical whitespace in various places that look unbalanced and make the content too spread out, and there is vertical whitespace lacking in the feed headings. See the attachments for before and after fixing these oddities that make the design feel more cohesive, polished and readable.

freebsd.fortasse.cloud.pdf267 KBDownload

jrtc27-freebsd.fortasse.cloud.pdf267 KBDownload

@jrtc27 Where did you make these changes? I can see from the PDFs it is a 'nicer' look — I'd like to put your changes into this edit. Feel free to either ping me the changes as a diff, or just tell me and I'll update the files :) Many thanks!

Will you also be implementing this for csu for static binaries (often forgotten, including by me in the past)?

That's... unhelpful. Also not sure how I managed to miss testing that case :(

(Also this applies equally to Linux, and I believe also on FreeBSD with CROSS_TOOLCHAIN=, though the latter only gets noticed if the host's tools are old enough)

.gitattributes is a footgun and can give confusing behaviour. tools/build/checkstyle9.pl should enforce this for GitHub PRs already, and clang-format can (will?) normalise this too. There are significant downsides for this with little benefit that I can see.

In D54399#1243356, @jhb wrote:

Hmm, looking at the code both before and after this change on armv7, it is just using plain ldrh and strh which will fault on unaligned accesses?

Personally I would avoid confusing GNU C underaligned attributes and just write it in ISO C using memcpy. LLVM will inline the memcpy as load(s) based on the target's unaligned access support anyway. That is:

On this point specifically:

Your response reads to me as dismissive, and this annoys me. Yes, it does not need to be perfect. However, it needs to be good enough, and the feedback I gave was for various aspects in which I do not believe it is good enough for the project. Once live, the world will have to see and deal with it. I have no clue how long it will take to fix the issues I see that make the site look unprofessional or be painful to navigate. This is compounded by the fact that there has been no recent attempt to solicit feedback and get buy-in from the developer community. This feels like it's being pushed forward whether we like it or not, and that is not a good way to build goodwill. I hope you rethink this strategy and don't continue to burn bridges with the developer community.

Oh and what happened to the sidebar for various pages like https://freebsd.fortasse.cloud/where/? They feel rather lacking without that (pages of text and tables with a lot of empty space around them), and there are various pages on the site I've never known how to find without the sidebar...

Other bug reports (all on Safari):

Just looking at the homepage there is some very strange use of whitespace: specifically, there is a lot of extra vertical whitespace in various places that look unbalanced and make the content too spread out, and there is vertical whitespace lacking in the feed headings. See the attachments for before and after fixing these oddities that make the design feel more cohesive, polished and readable.

Move INSTALLEXTRAKERNELS after NO_INSTALLEXTRAKERNELS is set. Hidden by testing originally on CheriBSD where we set NO_INSTALLEXTRAKERNELS to no early for Morello..

D54291

In D54282#1240665, @ivy wrote:

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

So the current code tries 10 times to hit a failure, and will use the last value if all 10 reads succeeded, given the condition after the loop is correct? Importantly, there's no security issue here, because we didn't actually report a successful read when it failed?