Page MenuHomeFreeBSD

bhyve: improve memory size documentation
ClosedPublic

Authored by novel on Jun 24 2016, 1:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, May 6, 11:51 PM
Unknown Object (File)
Thu, May 2, 7:03 PM
Unknown Object (File)
Thu, May 2, 3:46 PM
Unknown Object (File)
Thu, May 2, 3:46 PM
Unknown Object (File)
Thu, May 2, 3:46 PM
Unknown Object (File)
Thu, May 2, 3:10 PM
Unknown Object (File)
Mar 25 2024, 9:48 AM
Unknown Object (File)
Mar 22 2024, 9:06 PM
Subscribers

Details

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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

novel retitled this revision from to bhyve: improve memory size documentation.
novel updated this object.
novel edited the test plan for this revision. (Show Details)
novel added reviewers: neel, grehan, wblock, Doc Committers.
novel set the repository for this revision to rS FreeBSD src repository - subversion.
novel edited edge metadata.
usr.sbin/bhyve/bhyve.8
120 ↗(On Diff #17844)

This can be a little shorter and simpler:

.Ar memsize
defaults to 256M.

Changed default memsize default value wording.

usr.sbin/bhyve/bhyve.8
120 ↗(On Diff #17844)

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 edited edge metadata.

I'm fine with this.

This revision is now accepted and ready to land.Jun 24 2016, 10:32 PM
wblock edited edge metadata.

I'm fine with this.

Me too.

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?

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

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.

In D6952#146021, @novel 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.

This revision was automatically updated to reflect the committed changes.