Age | Commit message (Collapse) | Author |
|
and store it in a const variable for use by crt0.
help from kettenis and miod
|
|
ok guenther
|
|
|
|
an implementation detail for the kernel, libc, and libkvm,
and should not be a concern for others.
|
|
passed in a specific call.
From discussion with schwarze@ and jmc@
ok jmc@
|
|
From discussion with schwarze@ and jmc@
ok jmc@
|
|
|
|
text more generic
|
|
ok guenther
|
|
|
|
|
|
commited ye -- waiting for enough people to run kernels which support
the system call.
ok jmc
|
|
it are now unpadded
ok kettenis guenther
|
|
|
|
ok miod@ kn@ deraadt@
|
|
ok jmc@ schwarze@
|
|
exposed in a new field returned by sysctl(KERN_PROC). Update
pthread_{get,set}_name_np(3) to use the syscalls. Show them, when
set, in ps -H and top -H output.
libc and libpthread minor bumps
ok mpi@, mvs@, deraadt@
|
|
getpid() appeared (undocumented) in v5. Between v6 and v7 there is an
extra return value for the parent process ID.
getppid() did not appear in v7, it appeared in 32v libc. But getppid()
predates 32v. It seems to have been in earlier USG releases such as
Generic 3 (PG-1C300 Issue 3) as the MERT Release 0 manual references it.
getppid() didn't become a system call until 4.3BSD-Reno
omit most of these details and just mention v5 and 32v
with and ok schwarze@
|
|
joint work with and OK jsg@
|
|
tuhs/Distributions/Research/Dennis_v4/v4man.tar.gz has
manx/profil.2 but no man2/profil.2
the nsys sysent.c has '&nullsys, /* 44 = prof */'
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/sysent.c
profil(2) is first listed as v5 in the Combined Tables of Contents from
McIlroy's A Research UNIX Reader.
https://marc.info/?l=tuhs&m=158099986005023&w=2
and is present in
tuhs/Distributions/Research/Dennis_v5/v5man.pdf
ok schwarze@
|
|
ok schwarze@
|
|
any changes not taken noted on tech, but chiefly here i did not take the
cancelation - cancellation changes;
|
|
- on guenther's advice, remove NOTES: the text is either not relevant
or already described correctly elsewhere
ok guenther
|
|
from FreeBSD and NetBSD.
ok kettenis@ jmc@ espie@
|
|
|
|
of built-in cancelation points.
|
|
it either failed, or succeeded but didn't put a status into infop.
ok millert@
|
|
while here, wrap some long lines;
|
|
(SRTT) instead of the timestamp option. Since the timestamp option is
disabled on some OSs (eg. Windows) or dropped by some
firewalls/routers, in such a case the window size had been fixed at
16KB, this limits throughput at very low on high latency networks.
Also replace "tcp_now" from 2HZ tick counter to binuptime in
milliseconds to calculate the SRTT better.
tested by krw matthieu jmatthew dlg djm stu stsp
ok claudio
|
|
|
|
PROT_READ | PROT_WRITE to the less permissive PROT_READ. This one-way
operation is permitted for an introductory period to observe how software
uses this mechanism. It may change to require explicit mutable region
annotation with __attribute__((section(".openbsd.mutable"))) and explicit
calls to mimmutable().
^^^ Decided we'll do that for now, since we've only discovered one program
trying to be clever so far (chrome is trying to do something smart, and
mimmutable makes it even better)
discussed with kettenis and robert
|
|
Minor bump to both libc and libpthread: make sure you install a new kernel!
ok millert@, deraadt@
|
|
while here, wrap long line
|
|
mandoc suggestions & help from jmc
|
|
|
|
|
|
ok kettenis
|
|
ok deraadt
|
|
from josiah frentsos, tweaked by schwarze
ok schwarze
|
|
|
|
Feedback tb@, miod@, jca@
OK jca@
|
|
OK millert@ deraadt@
|
|
Both are correct, but "4.0" avoids the misunderstanding that we were
talking about any unspecified 4.xBSD release, and it is much more widely
used in our manuals.
Discussed with jsg@ in the context of other manual pages.
|
|
ok schwarze@
|
|
ok guenther
|
|
Alan Glasser describes the incident that led to access(2) in
https://minnie.tuhs.org/pipermail/tuhs/2021-November/024657.html
access(2) alarm(2) pause(2) were also part of the "50 changes" tape
post v6 "50 bugs" / "diff tape" / "50 fixes" tape (Salus QCU, pp 138-139)
"fifty changes" tape
https://www.oreilly.com/openbook/opensources/book/kirkmck.html
"50 changes"
https://archive.org/details/unix_news_november-1976
tuhs/Applications/Spencer_Tapes/unsw3.tar.gz
usr/sys/v6unix/changenotes
45) The "access()" system call checks access permissions on the real
id's of the process regardless of the effective ones. Doesn't return
stats, just does an internal "access()" to set u.u_error.
48) "alarm()" and "pause()" system calls are in to provide a user-mode
timeout capability.
with and ok schwarze@
|
|
ok jmc@ schwarze@
|
|
The timecounting subsystem computes elapsed time by scaling (64 bits)
the difference between two counter values (32 bits at most) up into a
struct bintime (128 bits).
Under normal circumstances it is sufficient to do this with 64-bit
multiplication, like this:
struct bintime bt;
bt.sec = 0;
bt.frac = th->tc_scale * tc_delta(th);
However, if tc_delta() exceeds 1 second's worth of counter ticks, that
multiplication overflows. The result is that the monotonic clock appears
to jump backwards.
When can this happen? In practice, I have seen it when trying to
compile LLVM on an EdgeRouter Lite when using an SD card as the
backing disk. The box gets stuck in swap, the hardclock(9) is
delayed, and we appear to "lose time".
To avoid this overflow we need to compute the full 96-bit product of
the delta and the scale.
This commit adds TIMECOUNT_TO_BINTIME(), a function for computing that
full product, to sys/time.h. The patch puts the new function to use
in lib/libc/sys/microtime.c and sys/kern/kern_tc.c.
(The commit also reorganizes some of our high resolution bintime code
so that we always read the timecounter first.)
Doing the full 96-bit multiplication is between 0% and 15% slower than
doing the cheaper 64-bit multiplication on amd64. Measuring a precise
difference is extremely difficult because the computation is already
quite fast.
I would guess that the cost is slightly higher than that on 32-bit
platforms. Nobody ever volunteered to test, so this remains a guess.
Thread: https://marc.info/?l=openbsd-tech&m=163424607918042&w=2
6 month bump: https://marc.info/?l=openbsd-tech&m=165124251401342&w=2
Committed after 9 months without review.
|
|
|
|
|