Age | Commit message (Collapse) | Author |
|
|
|
|
|
When we resume from a suspend we use the time from the RTC to advance
the system offset. This changes the UTC to match what the RTC has given
us while increasing the system uptime to account for the time we were
suspended.
Currently we decide whether to change to the RTC time in tc_setclock()
by comparing the new offset with the th_offset member. This is wrong.
th_offset is the *minimum* possible value for the offset, not the "real
offset". We need to perform the comparison within tc_windup() after
updating th_offset, otherwise we might rewind said offset.
Because we're now doing the comparison within tc_windup() we ought to
move naptime into the timehands. This means we now need a way to safely
read the naptime to compute the value of CLOCK_UPTIME for userspace.
Enter nanoruntime(9); it increases monotonically from boot but does not
jump forward after a resume like nanouptime(9).
|
|
OK sthen espie
|
|
|
|
makes it possible to jump to the examine command from within $PAGER.
ok kn@ schwarze@
|
|
|
|
|
|
ok kettenis
|
|
suggested by and ok stsp
|
|
configuration file.", but occasionally something else fit better; at the
same time, try to make the format for FILES more consistent;
original diff from clematis
|
|
OK kettenis@
|
|
spotted by stsp while reviewing the diff;
ok stsp
|
|
ok sthen@, patrick@
|
|
ok jan
|
|
noticed by clematis at insiberia dot net
|
|
descriptors runs below the low watermark.
The em(4) firmware seems not to work properly with just a few descriptors in
the receive ring. Thus, we use the low water mark as an indicator instead of
zero descriptors, which causes deadlocks.
ok kettenis@
|
|
that have arguments. Document this requirement/recommendation in style(9)
prompted by mpi@
ok deraadt@
|
|
|
|
It has become increasingly difficult to make sense of wireless man pages
without resorting to Wikipedia for help. My goal is to provide background
information about technical terms used across wireless man pages, such as
"MIMO" and "MCS". jmc@ suggested that ifmedia(4) would be a suitable place.
This new ifmedia(4) section provides context and equips curious readers
with additional technical terms to research if they wish.
Information about how 802.11 transmission rates work (roughly) and how they
evolved with each standard revision we support has been added.
Obsolete information about 2GHz restrictions in France has been removed.
Information about 5GHz channels has been added.
High-level information (11a/b/g/n/ac mode, hostap/ibss/monitor mode,
information about channels) is discussed before going into detailed
discussion about 802.11 data rates.
ok jmc@ schwarze@
|
|
on armv7/arm64. ok deraadt
|
|
feedback and okay schwarze@
|
|
|
|
|
|
|
|
|
|
|
|
The previous wording could imply that "options inet6" did set
RES_USE_INET6 on OpenBSD but that RES_USE_INET6 had no effect.
The truth is, "options inet6" isn't recognized by libc/asr, but
RES_USE_INET6 has an effect on OpenBSD.
So first state that "options inet6" does nothing on our system, then
describe concisely what it used to do/what it does on other systems.
Prompted by a diff from solene@, claudio@ insisted that we keep
dcumenting this option. ok eric@ deraadt@ solene@
|
|
feedback and OK espie@, and OK jmc@ on an earlier version
|
|
|
|
|
|
Prompted by a question from schwarze@
ok deraadt@, schwarze@, visa@
|
|
|
|
|
|
|
|
|
|
against root-only device nodes.
|
|
Add the missing paragraph to explain that the control device may be
read. Add the missing .Xr to sndioctl and sioctl_open.
ok and tweaks jmc@
|
|
though I don't quite know where to add it in the manpage text proper
fetch ? distfiles ? clean=dist ? somewhere else ?
|
|
|
|
|
|
|
|
ok jmc@ deraadt@
"thanks and don't wait for me" patrick@
|
|
|
|
ok patrick@
|
|
|
|
|
|
|
|
|
|
|