Why not properly namespace these with an ipf_ prefix whilst you're at it?

In D54221#1238719, @kib wrote:

In D54221#1238704, @jrtc27 wrote:

IMO the commits that added the icache sync were done due to some actual problems seen.

Probably due to a broken pmap (at least at the time) then.

You mean, flushing i- or d-cache when doing mprotect? The MI VM only calls into pmap_protect() when removing protection. For cases of upgrading access rights, it is left to pmap_enter(). IOW, it is rather complicated for pmap, and I think that explicit isync calls from userspace are better.

IMO the commits that added the icache sync were done due to some actual problems seen.

in principle, non-plt relocations can modify any kind of segments. There are DT_TEXTREL binries, as well as nothing in ELF spec prevents existence of PF_W|PF_X segment with relocs.
IMO the commits that added the icache sync were done due to some actual problems seen.

In D53898#1237357, @jhb wrote:

Hmm, so does (vm_offset_t)&end still work after this change or should it instead drop the &?

I strongly believe that we should making the claimed description a reality before adopting it. That is, there are known deficiencies with pkgbase where the current implementation is not yet at parity with distribution sets, and until those are resolved we should be honest with the fact that pkgbase is not yet fully ready for adoption.

This cannot just be made unconditional, building on non-FreeBSD with NOPKGBASE=yes NOPKG=yes needs to not attempt to use pkg in any way.

In D52303#1235848, @michaelo wrote:

In D52303#1235845, @jrtc27 wrote:

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

You consider a mess endian format easier to read with RFC timezones people need to look up? Can you enumarate all of them? Have you read my previous message? I am not printing seconds since epoch.

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

I believe the right thing to do is just set LC_ALL=C in the places where it matters. Seconds since epoch is a horrible format to put in human-readable strings. Most of the existing uses of date already set LC_ALL=C, either explicitly for that command or implicitly from earlier in the script (such as both newvers.sh).

There was nothing for me to check. My concern was, and still is, how human-unfriendly the format is, instead of just fixing the locale.

My existing comments still stand. AFAICT the latest revision just rebased it?

In D54018#1234972, @markj wrote:

In D54018#1234971, @jrtc27 wrote:

Why not just replace the entirety of barrier.[ch] with pthread_barrier(3)?

I had the same thought, but apparently macOS doesn't implement it.

Why not just replace the entirety of barrier.[ch] with pthread_barrier(3)?

_ALIGNBYTES seems a bit underspecified and/or fraught. max_align_t is often higher than void * thanks to long double and/or int128. It would probably be more prudent to adapt to being explicit about what alignment each use case needs; many probably should be using max_align_t, or alignof(some struct being allocated). Then _ALIGNBYTES can remain for legacy use cases like cmsghdr where it's part of the ABI.

s/extern char/&[]/ in the subject, also &end is not char * in that case, it's char (*)[], which is an incomplete type so you can't perform pointer arithmetic on it (as sizeof(char[]) is not known). end itself decays to a char * and so pointer arithmetic on *that* works (or &end[0], but decaying is cleaner). In this case though there's an explicit cast before the arithmetic so both "work".

In D53817#1229572, @markj wrote:

In D53817#1229564, @brooks wrote:

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Me neither, but it's a lot of churn to remove at least vm_offset_t. vm_paddr_t and vm_pindex_t have no obvious substitute. vm_ooffset_t would have to be uint64ptr_t I think.

In D53819#1229986, @brooks wrote:

In D53819#1229955, @kib wrote:

And where is __intcap_t defined? Is it provided by some MD include, like machine/_types.h?

I do not remember seeing this MD define in the review series. If true, then should __intcap_t added before the use?

__intcap_t is a new primitive type provided by the compiler. It cannot be defined by a header except on systems that don't support it.

In D52526#1228284, @arichardson wrote:

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

Thanks for committing this. Do we still need the && defined(__USE_GNU)? Technically it's needed but I guess this file is only every compiled with -D_GNU_SOURCE so probably doesn't matter?

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

New scripts need to be added to OptionalObsoleteFiles

You were exactly a month late for October 3rd... :)

Maybe a description along the lines of: