Updates the install's maximum file size of a file to select it for comparison with the -C flag.

Update message.

Updating D57442: vt: Do not lock request comming from terminal, only those originated by

mouse. Because the terminal surrounds requests to vt(4) with locking.

In D57271#1312567, @glebius wrote:

Makes sense to me. Thanks for good explanation in the commit message.

Fix new-line.
Report unhandled case.

In D57247#1312477, @asomers wrote:

Not really a domain expert, either, am I. Can you give me a clue about how to test this? I can use virtio-scsi with bhyve. But how does one tell bhyve to tell the guest that the storage capacity has changed?

Hey, Alan!
Thanks for joining!
bhyve is unable. At least yet :)
I did it with qemu:

In D57230#1311556, @glebius wrote:

I'd suggest to split the default increase and the added new option into two separate commits.

The commit that increases the default should have some data to back the decision made. E.g. installworld time decreased by that many seconds.

Move the hard-coded limit to separate commit.

Invite asomers, andrew, and kib to help with review.
Thanks, guys!

In D57231#1311555, @glebius wrote:

To me this looks like a more generic problem rather than just the watchdogd's problem. Should every daemon have this feature? Or should we say that /var/run shall be mdmfs(8) on hosts with read-only root?

I added authors of the pidfile(3) to add people who definitely thought a lot on this problem.

In D57247#1311835, @glebius wrote:

P.S. Oleksandr, if you got review from any other domain expert than Warner, consider this approved by mentor (me).

Update usage.

Completed in D35609.

In D32319#1281516, @ali_mashtizadeh.com wrote:

It looks like we landed some version of this diff already? Should we close it?

https://docs.freebsd.org/en/books/handbook/usb-device-mode/

Hey Alexander!

Looks better now :)

Many thanks, Mitchell!

Look good to me. Thanks!

Hi guys,
basically, I agree with Hans and not sure it will behave well w/o spinlock.
But that way VT will be faster and machine performance will be better.
/me vote to try

Agree.
The use of a Parallel NOR Flash is infrequent nowadays. And virtual mapping of an SPI NOR Flash I saw only on MIPS SoCs.

Looks good to me.
Thanks!

In D32316#741213, @emaste wrote:

@ray I assume you can go ahead with committing this one?

In D32335#747099, @gbe wrote:

Could you ran 'mandoc -Tlint' over the man page. There are plenty of warnings, which could easily be fixed, like 'new sentence, new line' and so on. It would be nice if you could also add the author of the man page.

And you have to include this man page in the makefile of the directory.

Fix formating according to mandoc lint hints.

Fixed. Thanks for review!

Review fixes.

All fixed. Thanks for review, Mitchell!

style(9) changes.

In D32670#747725, @mhorne wrote:

Oh yes, and one question. Should sys/dev/hwpmc/pmu_dmc620.c be located elsewhere, similar to sys/arm64/arm64/cmn600.c? To me, it does not seem to belong in the hwpmc sub-directory.

Cleanup.

Remove debug leftover.

Done comments.

In D32316#737876, @mhorne wrote:

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

Update classes base ri to handle optional classes out of order.

LGTM
Thanks!

I like it.
Thanks!

LGTM
Thanks!

Squash commits.

Fix comment.

In D30047#676281, @mhorne wrote:

This looks fine to me, thanks for fixing this.

It seems that pmc_id_t should be an opaque type for consumers of libpmc? I.e. the only userspace consumer of these bit macros should be libpmc itself.

If that is the case, then this change should be okay without a PMC_VERSION bump. There are no uses of PMC_ID_TO_MODE or PMC_ID_MAKE_ID in libpmc. However, I did not check if this was true for older releases.

Looks fine.
Thanks!