As a general rule I prefer positive-sense controls - so e.g. "enable_thermal_limit" or "thermal_limit.enable" (if we're also going to have a "thermal_limit.count or such), and it can default to true.

I think the change overall is good -- the example is certainly impmroved. I still think it's better w/o adding "service" though. There isn't really a Wi-Fi interface service. Something like "Reconfigure and restart network configuration and dameons related to the Wi-Fi interface" would be pedantically correct but terribly wordy. "Restart the netif service for the Wi-Fi interface" is short but still awkward.

What service is being restarted though?

The previous text Restart the network interface daemon wasn't completely accurate before, but I think it's close enough that inaccuracy can be hand-waved away. Now that daemon on the Wi-Fi interface is more specific it seems more important to be accurate.

(Discussed on the mailing list at https://lists.freebsd.org/archives/freebsd-net/2024-May/004920.html)

The sense of the flag should be inverted: otherwise the capability mode functionality will not get much testing IMHO. In the long run, we should remove the flag entirely.

Was introduced in commit rG:e548a1d4c8cce0f67b82d6d5387847c7551de6c4

Note that these are currently accessed in libexec/rc/rc.d/linux:

In D55687#1356375, @aokblast wrote:

@bapt Hi, My version has been merged by @emaste. Could you please close this?

Change looks fine to me. Agree w/ Adrian that the commit message can be shortened significantly.

Yes, please go ahead and land this. I'll rebase the 10.5 work on top of it, no problem.

I think you should commit D52203 now, I will rebase this change after.

Any comment on the other question @imp? I.e., why don't we use .if ${_uid} != 0 in bsd.dirs.mk also?

Looks fine, but shouldn't this and bsd.dirs.mk have the same (${_uid} != 0) logic?

In practice we probably expect a single-digit callback count, and most likely only one or maybe two, so an O(n) loop over the list to check for a duplicate ID should be OK (we're already doing this regularly anyway).

Add XXX comment. Will be in separate commit with

We should probably pick one and use it consistently. Some quick git grep showed the following counts in our tree:

"debugging symbols" isn't best, because these are not just symbols.

Rebase @aokblast's ce9ced951a0b9d004a3b007d4ac6e9087a1301a2

OK