So why both? Pnpbios? I'd like to understand that before we start adding layer violating hacks. It's just one device and i wonder why we see two views that don't naturally hit a resource conflict... or even why we do both enumerations.

FWIW, we do not disable EFI RT timer services when we attach to rtc, and in reverse. I am not sure, might be we should. Right now we lock accesses according to the UEFI spec recommendation.

This change is super confusing. Why are some cr* converted to crcow* and others (rest of the kernel) not? I'm porting this to downstream changes. It's not great that _credential code_ is this confusing and inconsistent.

Thanks for tagging me!

Address review feedback: keep warn variable, invert at assignment instead of double-negative

Is there a way to look up whether or not rtc(4) is attached using the bus_(9) APIs instead of using this one-off sentinel?

@imp, @jhb, @kib: do any of you have any strong opinions with this proposed change?

Looks good with one additional minor fix

Editings by olce.

Add assert that ast handler is called for curthread.

Awesome!

In D54762#1252920, @adrian wrote:

Any other comments? I'd like to land this into -HEAD this week and see how it plays out!

Okay, I see. if_inc_counter() is implemented with counter_u64_add which is atomic on arm64, i.e. no synchronization is required. I don't think there's noticeable overhead either, i.e. lgtm.

In D54941#1256407, @ngie wrote:

Simplify. Use TDP_SCHED1 instead of the new field in the ts structure.

@brooks : not sure if my tree is out of date, but I found a few more references of potential concern:

% rg -l '\(resultproc_t\)' worktree/main/ | sort
worktree/main/contrib/netbsd-tests/lib/libc/rpc/t_rpc.c
worktree/main/lib/libc/rpc/rpc_soc.c
worktree/main/usr.bin/rpcinfo/rpcinfo.c
worktree/main/usr.bin/rup/rup.c
worktree/main/usr.bin/rusers/rusers.c
worktree/main/usr.sbin/bootparamd/callbootd/callbootd.c
worktree/main/usr.sbin/ypbind/ypbind.c

Do those need to be changed?

It looks good to me. And I see that with --libxo=json, these errors append a {}. Are there any other cases where they do something differently than err?

I double checked, the counters are part of the information provided by the ioctl SIOCGIFDATA.

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

I have some more pseudofs patches in the pipeline still, I'll look at being consistent there as follow-up

Handle kernel MOE exceptions.