Page MenuHomeFreeBSD

vt: Fix and sync setting scrollback (history) docs
Needs ReviewPublic

Authored by ziaee on Sat, Oct 10, 2:36 PM.
Tags
None
Referenced Files
F175929920: D60586.id189797.diff
Wed, Oct 14, 2:27 PM
F175929882: D60586.id189797.diff
Wed, Oct 14, 2:27 PM
F175884366: D60586.id189797.diff
Wed, Oct 14, 4:49 AM
F175881975: D60586.id189797.diff
Wed, Oct 14, 4:15 AM
F175863922: D60586.diff
Wed, Oct 14, 12:21 AM
Unknown Object (File)
Tue, Oct 13, 4:11 PM
Unknown Object (File)
Tue, Oct 13, 3:39 PM
Unknown Object (File)
Mon, Oct 12, 10:23 PM
Subscribers

Details

Reviewers
adrian
emaste
bcr
Group Reviewers
manpages
Summary

So, this was wrong in two places. The first one, I wrote, so... Sorry.
The second one... should we dig deeper? was the doc right initially?
Like does sc work differently than vt here and that is why?

MFC after: 3 days
Fixes: a8740ba860bf ("vt: Document increasing scrollback size")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 77961
Build 74844: arc lint + arc unit

Event Timeline

ziaee requested review of this revision.Sat, Oct 10, 2:36 PM
bcr added a subscriber: bcr.

Good to go from manpages.

This revision is now accepted and ready to land.Sun, Oct 11, 9:02 AM
jilles added inline comments.
share/man/man5/rc.conf.5
3527

typo

Hmm, so I guess the real thing is you just want to document the maximum supported value? I think doing that in examples is not great actually. I would rather add a note to the description of the -h option in vt.8 describing the range of acceptable values and leave these examples alone unless they are describing invalid values (which the first example seems to be doing). So I would suggest dropping the change to rc.conf.5 entirely, tweaking the example in vt.8 to use a valid value and then add new text for the -h option to describe the range of accepted values.

share/man/man4/vt.4
363

"add" in the old text seems fine to me FWIW, "insert" would be a bit less colloquial than "put" perhaps?

Note that 16384 is not an intentionally set limit, it is just a consequence of an expression to ensure we don't have an integer overflow. It is somewhat conservative and could be made higher if there's a desire to do so.

Also the kernel returns EINVAL for values too large, but we could equally easily cap it at the maximum instead of rejecting values too high, if we want.

jilles: fixed thanks
jhb: rc.conf.5 is wrong, allscreens_kbdflags does not accept -h. we dont have vt.8, but i did add suggested default and maximum to vidcontrol.8, thanks. i dont want to leave it at just that because vidocontrol is arcane and mostly doesnt work for vt.
emaste: 16384 is really unbeliably tiny. the default 100 is completely useless and can not even show a pkg upgrade, but that makes sense since people dont actually use the console generally

This revision now requires review to proceed.Tue, Oct 13, 9:24 PM