bhyve: improve memory size documentation

[novel]

Summary

A couple of minor memory size option related nits:

• use common name 'memsize' (instead of 'max-size' or just 'size')
• bhyve: update usage with memsize unit suffix, drop legacy "MB" unit
• bhyveload: update usage with memsize unit suffix
• bhyve(8): document default size
• bhyveload(8): use memsize formatting like it's done in bhyve(8)

Test Plan

%> LC_ALL=C igor -R bhyve/bhyve.8
%> LC_ALL=C mandoc -Tlint bhyve/bhyve.8
%> LC_ALL=C igor -R bhyveload/bhyveload.8
bhyveload.8:78:sentence not on new line:unbuffered standard I/O. This is the default value.
%> LC_ALL=C mandoc -Tlint bhyveload/bhyveload.8
%>

PS That bhyveload warning is not related to the change.

[wblock]

usr.sbin/bhyve/bhyve.8

120

This can be a little shorter and simpler:

.Ar memsize
defaults to 256M.

[novel]

Changed default memsize default value wording.

[novel]

usr.sbin/bhyve/bhyve.8

120

Yeah. I just copy/pasted that from bhyveload.8 that does mention it. Now I changed that in both places in a way you suggested.

[grehan]

I'm fine with this.

[wblock]

In D6952#145924, @grehan wrote:

I'm fine with this.

Me too.

[novel]

Thanks for reviewing!

Should I request re@ approval for that (as it's more of a documentation change) or it's better to wait for when freeze is over?

[wblock]

In D6952#146008, @novel wrote:

Thanks for reviewing!

Should I request re@ approval for that (as it's more of a documentation change) or it's better to wait for when freeze is over?

During a freeze, commits are prevented unless they have re@ approval. There is a specific guide for what is desired, but of course it's not in the Committer's Guide (I would welcome a review for *that*), it's on the wiki: https://wiki.freebsd.org/Releng/ChangeRequestGuidelines

[novel]

In D6952#146020, @wblock wrote:

In D6952#146008, @novel wrote:

Thanks for reviewing!

Should I request re@ approval for that (as it's more of a documentation change) or it's better to wait for when freeze is over?

During a freeze, commits are prevented unless they have re@ approval. There is a specific guide for what is desired, but of course it's not in the Committer's Guide (I would welcome a review for *that*), it's on the wiki: https://wiki.freebsd.org/Releng/ChangeRequestGuidelines

Thanks for the pointer. Actually, my question was mostly if this change is worth pushing now (rather than waiting for unfreeze). If it is, I'll follow the steps described in the doc.

[wblock]

In D6952#146021, @novel wrote:

In D6952#146020, @wblock wrote:

In D6952#146008, @novel wrote:

Thanks for reviewing!

Should I request re@ approval for that (as it's more of a documentation change) or it's better to wait for when freeze is over?

During a freeze, commits are prevented unless they have re@ approval. There is a specific guide for what is desired, but of course it's not in the Committer's Guide (I would welcome a review for *that*), it's on the wiki: https://wiki.freebsd.org/Releng/ChangeRequestGuidelines

Thanks for the pointer. Actually, my question was mostly if this change is worth pushing now (rather than waiting for unfreeze). If it is, I'll follow the steps described in the doc.

Since it does not change any functional code (no additional testing for re@), and does improve the documentation, I would say it is worth adding now. re@ might not agree depending on their situation, but it's relatively easy to find out.