One nit.

I'd be happy to approve a revision of this based on the latest upstream submission by @iwtcex_gmail.com.

This should be closed a superseded by https://reviews.freebsd.org/D56178 - alas I cannot find how to make this change in Phabricator.

Thank you very much for adding the check logic.

Excellent, then let's have this in the handbook. Approved!

In D58166#1334136, @dudleyi_yahoo.com wrote:

@carlavilla this seems to be a problem spread across multiple handbook languages. I did not scrub through them all, but I am sure there are more instances of this issue.

I committed my diff switching branch names to macros. However there are other improvements in this patch that could be rebased.

Read this in its entirety, astonishing job. Thank you so much for working on this!

ping

Amazing to read through this rewrite. It is a much needed and substantial rewrite/update of most of the chapter. I only found this small nit.
Make sure to reference Bug 287148, Bug 261212, and maybe even Bug 263321. Thank you very much!

In D57885#1334360, @dch wrote:

Sigh, it's already set in L28... but if the file isn't present, it needs to be created with correct permissions, otherwise it won't be set. Can you add that please?

Sigh, it's already set in L28... but if the file isn't present, it needs to be created with correct permissions, otherwise it won't be set. Can you add that please?

LGTM, thank you.

In D57885#1334350, @dch wrote:

• needs a PORTREVISION bump

Oh I see

• needs a PORTREVISION bump
• what happens in the default case where buildkit_logfile is not set?

thanks! LGTM

In D52166#1330369, @adrian wrote:

Hey, any further traction on this? What's left before it can be landed?

Thanks for your review @bnovkov

Reflect bnovkov's review

LGTM with the highlighted attribution fix. Thanks for writing this!

Please remember to set the author on this one. git commit --amend --author="Jim Brown <jpb@jimby.name>". He stopped contributing because we were not giving him enough attention.

I support this since we do not even have doc on uefisign yet, or have built any tooling around it. This is a win for consistency and reduced operator mental load. We also need to update these files:

$ cd src; git grep uefisign
etc/mtree/BSD.usr.dist:            uefisign
share/man/man8/uefi.8:.Xr uefisign 8
targets/pseudo/userland/Makefile.depend:        usr.sbin/uefisign \

\o/

LGTM!

Fixes

reflect olce@'s comment

Reflect olce@'s comment

In D57825#1333484, @olce wrote:

Looks good. One suggestion in an inline comment. Only thing now is the dependency on the CPPC lib, I'll review the other revisions and come back to here.

In D55474#1333882, @olce wrote:

Two more things to consider. First, you finally reduce items expected to be read-only to an integer (field value in struct acpi_cppc_rdonly_item), but some of these are dynamic and may change during runtime, in which case we have to keep the full register specification. Second, in the _CPC example I sent you offline for an AMD machine where processors do not report the CPPC extended feature flag, most present items have the PCC access method, so won't be covered by the code here. In the same example, there are only two FFH, for the ReferencePerformanceCounterRegister and DeliveredPerformanceCounterRegister, and the addresses seem to correspond to the MPERF and APERF MSR numbers respectively.

In D55474#1333742, @olce wrote:

As noted on previous revisions, SYS_RES_FFH should not exist, nor should acpi_ffh_write() and acpi_ffh_read(). So, basically, this needs a full rework.