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?