@cperciva : ping?

I passed it back to @guest-seuros so he can look at the diff, make any desired changes, and get credit for the diff once it lands.

I waited too long to look at this and the version in the ports tree is now 0.7.0: closing.

Remove redundant _interface I added in the tunable name

Fix accidental build break

• Clean up comments regarding this feature and clarify items about how the OSI gets installed/removed.
• Add a bootverbose message to note when the quirk does not apply, i.e., when the logic is run on non-Apple platforms.
• Hide the OSI install message behind bootverbose.

What was the directory at this point in the tests prior to this change?

This seems to me like a very reasonable change. Thank you!

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.

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?

In D54762#1252920, @adrian wrote:

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

In D54941#1256407, @ngie wrote:

@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?

Merged to :main as rG46333229c6a0187ebf231805682ee0bceed704d1.

Does it make sense for FreeBSD to adopt the repo and maintain the component upstream like that :/?

In D54615#1248205, @guest-seuros wrote:

This module load only in apple hardware. Spparently the hardware is not build to have it driver hot reloaded.

System boot -> unload driver -> ok -> load it again -> panic (resources were not freed) (need a full reboot)

In D54613#1248760, @markj wrote:

In D54613#1248261, @guest-seuros wrote:

We could wrap it with a sleep mutex, but concurrent fan control from multiple threads is not a realistic scenario.

It could be, if you have a daemon which manages fan speeds in the background and you concurrently adjust something from a shell.

The worst case is a lost update, not a crash.

My approach is to upgrade to MPSAFE, stress test on real hardware, then ship.
That's also why I'm not submitting upgrades for every drivers, I only upgrade what I can actually test on hardware I have.

A follow-up sweep can remove unnecessary locking where it makes no sense.

I won't argue much more, but this feels backwards: the other NEEDGIANT removal patches are fine since the driver handles locking, but here it's dubious since Giant is actually providing some serialization. This can be addressed without touching the existing locking, just add a driver lock on top.

Merged as D54436. Closing.

Definitely could be contributed upstream.

Would this please make this into a SYSCTL+TUNABLE? It would be nice if that's at all possible, because then you could do graphics switching post-boot. I don't know if it's possible, but it would be nice. macOS supports graphics switching dynamically at runtime/based on power states.
Also, are there any caveats associated with picking one of the GPUs over the other, e.g., one supports dual displays at a higher resolution, whereas the other only supports single displays at a lower resolution?

Is this behavior desirable? It seems very ambiguous to me...

Oof... that's a bit of an increase. Wonder if there's a way to improve things a bit more perf wise (I'd file a bug to track the investigation).

Abandoning as @mm is planning on cutting a new libarchive release soon which will include this fix (and others).

Ship it!
!ship-it-dog

sys/modules/asmc/Makefile: condense SRCS

In D41705#1244931, @ngie wrote:

I scrolled back several releases to see what our prior "Open Issues" sections look like.

In D54512#1245481, @ngie wrote:

BTW, isn't the proposed change what Errata Notes sort of do...?

BTW, isn't the proposed change what Errata Notes sort of do...?