Updated to use ${M_ListToSkip}

I was okay with not having the mask have an effect on the suid/sgid because there's already the mount option for nosuid (which disables suid and sgid both), so there's not really a need for the mask to alter it.

In D44629#1072114, @emaste wrote:

A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

I think it's a bit of a toss-up -- the set of targets in the two lists is not large and does not change frequently. I'll grant you that the two lists are somewhat nicer than the large set if if-or conditions, but N_$e= ${MACHINE_ARCH_LIST.$e:@m@N$m@:ts:} makes up for it by taking a while to figure out.

In D44629#1071811, @emaste wrote:

I'm a little confused by this change - it doesn't seem notably clearer to me.

Adjusted little endian list

In D45740#1043372, @glebius wrote:

In D45740#1043263, @zlei wrote:

The full diff is quite large ( about 7 megabytes ). See my dev branch https://github.com/gmshake/freebsd-src/tree/main_if_alloc instead, or I can upload the full diff if requested.

I'm not from Juniper :) I would guess Juniper is fine with the proposed changes. They care about IfAPI hiding 'struct ifnet' better and better as time goes by, they don't have a requirement for the API to be never ever changing. I'll add Stephen to reviewers to correct me.

Use atomic to read OSD slot data

In D45072#1028956, @mav wrote:

I wonder if there is any real architecture where pointer load/store is non-atomic. For things that are going to be executed between once and never it feels like you are over-engineering it. :)

Using atomics for fetching/modifying the decode function pointer

Replaced by review D45072, will address the review comments from this review in the newer one.

Updated based on review comments

In D39636#1023799, @brooks wrote:

What is the value of MK_VIMAGE_SUPPORT over MK_VIMAGE? We now have an unused MK_VIMAGE. What will it control?

This commit is missing an addition of tools/build/options/WITHOUT_VIMAGE and WITHOUT_VIMAGE_SUPPORT and breaks GitHub CI because makeman spots the missing files.

Updated according to review comments

Added parenthesis based on comments.

In D44928#1024386, @glebius wrote:

Or, this can go under SOCKET_HHOOK new option. Cause these two hhooks aren't really related. What do you think?

Changed from _nolock to _unlocked in naming and updated commit log message.

In D44811#1021514, @glebius wrote:

IMHO, such trivial changes do not require posting a review.

In D44529#1020279, @jhb wrote:

Looking at all those, I think we probably don't need a separate SI_SUB_DEVCTL_NOTIFY (though I wonder why that isn't SI_ORDER_FIRST), but I do think a separate SI_SUB_GEOM for GEOM classes to use (and the fdt_slicer thing) would be sensible. It could be defined as 0x3400000 and would untangle a bit of this more cleanly I think.

In D44620#1020403, @jhb wrote:

LGTM. If the file was using normal style it wouldn't need the indentation fixup (which will add a lot of noise). I would maybe suggest instead to fix the indentation to not be unusual in lieu of the one char fixup.

Do you want me to just switch things to use __unused instead of the macros to conditionally add it?

In D44623#1017858, @kib wrote:

In D44623#1017833, @markj wrote:

In D44623#1017481, @kib wrote:

I have some bad feeling about all that <feature>_unused macros. Would it better to change it to unconditionally apply unused globall?

I guess __unused has no effect if the compiler can observe that the annotated variable is in fact used? Maybe it would trigger warnings?

I don't really like all the __unused aliases either, but I also don't want to just use __unused everywhere, it would be confusing.

gcc manual describes the attribute((unused)) as possible unused, with the only mentioned consequence of gcc not issuing warning if really unused.

In D44632#1017491, @glebius wrote:

I was about to ask "where is #ifdef TCP_HHOOKS?" But then I realized that socket_hhh isn't hidden under any ifdef.

Unrelated to this review, but may I ask if it is possible to hide socket_hhh and other stuff that came in 4ec7371233268 under TCP_HHOOKS? Or maybe SOCKET_HHOOKS, if these two are used as two independent features.

Update summary

In D10469#794487, @emaste wrote:

There seems to be no change here or in https://github.com/trixirt/libc11ext in the last five years. @trix_juniper.net are you still planning to pursue this?

Made changes according to review comments.
Also fixed an issue when compiling gve_adminq.c due to the addition of
prototypes that use "bool", but the .c file was not including sys/types.h

Updated based on review comments

Updated based on review comments

In D44535#1015791, @andrew wrote:

Is there a reason to not have cpu_reset_hook = psci_reset by default so we can remove the NULL check?