sigh, turns out we need to fix something in sdt_machdep.h first:

Verified

In D54954#1256545, @ngie wrote:

In D54954#1256538, @imp wrote:

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.

I can't speak to the exact configuration, but @guest-seuros mentioned something in Discord about the machine being a Hackintosh based PC (which I think might fake the asmc(4) device) and the system having compatibility mode set in the BIOS.

Disabling compatibility mode fixed the issue, but I also recommended disabling the device in /boot/device.hints, if it's an environmental problem that isn't easy to fix.

In D54954#1256538, @imp wrote:

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.

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?