Rebase on D61139

Rebase main and update test

Add tests for PT_SETREGS while signal delivery

@jhb @olce Request for mentor approval.

@jhb @olce Request for mentor approval.

pep8 was renamed to pycodestyle but it does not come with phorge's arcanist. Another alternatives to flake8 are pylint and pyflakes, but pyflakes don't check pep8 and pylint is too strict and could generate false positives for our use case.

pylint->flake8

Remove llvm tests

I didn't know some use the workflow of importing git repository into a downstream svn/hg repository. I'm closing this revision and will create a new revision with cvs change only.

revert iic change

I don't use LSP for kernel development, but LSP users can try this out after merge and create bug reports if there are any issues.

ping @jhb and @olce for mentor approval

Add check to usb_handle_remote_wakeup()

Fix indent

• Fix indent, conditional, and typo
• Add ASM2 vendor

I opened a PR that moves i386 to EXTRA_ARCHES a while ago: https://github.com/freebsd/freebsd-src/pull/2052

If we use preprocessors instead of handwriting the scheduler-specific namespacing (e.g. sched_foo), how will it affect the following:

@jhb Is this ready for commit?

@jhb Is this ready to commit?

Ping @jhb and @olce for mentor approval

@olce Would you review this as scheduler?

@olce Would you review this as scheduler?

Ping @jhb for mentor approval

@jhb Is this ready for commit?

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

Sorry for delaying updating hmp(4). Currently my university lab is preparing to design a new thread replacement policy model for FreeBSD. I want to reflect that design to hmp(4) in advance so we can avoid major overhaul to the subsystem later. Right now we are preparing workload samples for benchmarks and I will notify you in this thread as soon as the design draft is completed.

Thank you for the update on the situation.

Regarding the "new thread replacement policy model for FreeBSD," are you intending to develop a new scheduler? If so, I look forward to it and would like to cooperate as much as possible.

Also, do you have plan to MFC this to stable/15? I don't see this being a breaking change to users and KPI/KBI.

LGTM, there are many small changes that would be in separate commits in normal cases, but since we are refactoring them anyways, I think they all can be squashed into this one commit.