In D44455#1287237, @koinec_yahoo.co.jp wrote:

Regarding the modification to save the acquired score values ​​from struct cpu_group to pcpu, I'd like to use the HMP (https://reviews.freebsd.org/D54674) API rather than creating a new, intelhfi's specific variable in pcpu for saving the values.
Are there any problems with this approach? If so, please let me know.

Thank you all for your comments.

I think I'm not qualified for MFV: someone with trust (= commit bit) in the community should take this work instead.

In D44455#1284367, @koinec_yahoo.co.jp wrote:

Thank you for letting me know the results of discussion on the implementation policy. I understand the policy.
I will start working on the revisions now, but given my current situation, I think it will take several months. Please give me some time.

After some considerations, I decided to abandon this revision based on the fact that kgdb(1) is a port and not in the base system. This means that if there is a need for this script, it should be provided via ports not through the base system. Also, I haven't heard any voice that wants this so it seems I'm trying to solve a problem that doesn't exist for now.

Thank you for letting me know the results of discussion on the implementation policy. I understand the policy.
I will start working on the revisions now, but given my current situation, I think it will take several months. Please give me some time.

Thank you for all your feedback and advice!
I have made the following corrections.

• Fix the driver name from uppercase to lowercase

Move non-POSIX options block in the STANDARDS section.

In D56090#1282965, @ziaee wrote:

The COMPATIBILITY section is a GNU-ism.

Thanks for the patch! The mdoc(7) manual explains that it's important to use standardized sections wherever possible to reinforce the idea that people can jump directly to the relevant section. The COMPATIBILITY section is a GNU-ism. Please put this in the STANDARDS section. Other than that, looks good to me!

Looks good to me. Thank you.

After talk with other FreeBSD dev at AsiaBSDCon, we concluded that score should be stored in pcpu structure, not in cpu_group for the following reasons:

LGTM, although we need approval from committer.

LGTM

Rebase current src-tree.

• Rebase current src-tree.

Could you rebase main?

Could you rebase main?

In D44456#1277852, @koinec_yahoo.co.jp wrote:

In D44456#1272317, @minsoochoo0122_proton.me wrote:

Can we enable/disable the whole module when one or both of HMP and SMP aren't enabled? I don't see why we need to build this driver when HMP and SMP don't exist.

Thank you for the advice.
As you advised, there's no need to build this driver without specifying the SMP option, so I removed "#if defined(SMP)".

However, to prevent accidental builds, I've added a build error using "#error" if it's undefined, but I'm not sure if this is the correct practice. Any advice would be appreciated.
Also, I think it would be better to remove "#if defined(HMP)" when the ULE scheduler support and the HMP interface code support you separately posted are officially merged, but what about leaving it in during development?

Note that even without including opt_sched.h, if SMP is defined in the kernel configuration, the build error caused by #error will not occur.

In D44456#1272317, @minsoochoo0122_proton.me wrote:

Can we enable/disable the whole module when one or both of HMP and SMP aren't enabled? I don't see why we need to build this driver when HMP and SMP don't exist.

• Remove the unnecessary inclusion of opt_sched.h.
• Modify the code to output an error (#error) if a required SMP kernel configuration option is not defined.

• Restore the NULL check for the handler function pointer in the lapic_handle_thermal(), which was mistakenly deleted.
• Fix an issue with the registration order of instance ptr. and handler function ptr. within the lapic_enable_thermal().

Superseded by D55838

refer to previous commit msg, just added /usr/share/firmware as another path in firmware_path[MAXPATHLEN]

used strchr(3) in try_binary_file() instead of manual parsing
ensured proper checking in try_binary_file(), and added a default for firmware_path in /stand/defaults/loader.conf
also removed TUNABLE_STR because CTLFLAG_RWTUN already sets it

In D55597#1272248, @mcq_disroot.org wrote:

Generated with U99999 for full context.

A couple of small suggestions, and one question that needs to be answered.

Can we enable/disable the whole module when one or both of HMP and SMP aren't enabled? I don't see why we need to build this driver when HMP and SMP don't exist.

Generated with U99999 for full context.

can you either use git arc to update this patch, or generate the diff with -U99999 please? I need a little more context to review it.

Modify to load and store handler function pointers using atomic(9) functions.