wireguard-openbsd/sys/arch/sh/include, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/sh/include?h=jd%2Fqueueboosts2020-05-31T06:23:56Zintroduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.2020-05-31T06:23:56Zdlgdlg@openbsd.org2020-05-31T06:23:56Zurn:sha1:01802d2cc63d886227ab3b39e923ff13cf516166
rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.
there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.
so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.
djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.
Retire <machine/varargs.h>.2020-05-27T15:16:04Zvisavisa@openbsd.org2020-05-27T15:16:04Zurn:sha1:9df0f941a91e9f67cc4e63514cb174cb2a5783fd
Nothing uses the header anymore.
OK deraadt@ mpi@
db_addr_t -> vaddr_t2019-11-07T16:08:07Zmpimpi@openbsd.org2019-11-07T16:08:07Zurn:sha1:52de38dfad83669953521277a64804bf85027c8eSubstitute boolean_t/TRUE/FALSE by int/1/0.2019-11-07T15:58:39Zmpimpi@openbsd.org2019-11-07T15:58:39Zurn:sha1:1d47df5535a8eecf36a407d475096db35dd70ad6Add intr_{disable,restore}() for sh.2019-03-24T06:09:09Zvisavisa@openbsd.org2019-03-24T06:09:09Zurn:sha1:d271d0a8fa79e4163245fa802c9a3397ab9c9ad4
Reminded by deraadt@
sprinle some casts to quiet compiler; ok millert2019-02-17T15:44:26Zderaadtderaadt@openbsd.org2019-02-17T15:44:26Zurn:sha1:e9a8150065b24ecdeb158fae3d19fa220ea67402Add END() macro to set symbol size like every other arch2018-11-11T20:15:24Zguentherguenther@openbsd.org2018-11-11T20:15:24Zurn:sha1:81a5d5c8702040f5e91cada2bc097ca40e7687ce
ok deraadt@
Provide an MD 64-bit byteswapping function build on 32-bit swaps2018-10-05T15:13:55Znaddynaddy@openbsd.org2018-10-05T15:13:55Zurn:sha1:8cba618e576f82477516a78a2b6621a1107a8a47
as we do on arm and i386. Copied from arm.
If there are no MD byteswapping functions, MI macros are used.
These are wrapped by static inline functions to prevent multiple
evaluation of their argument. If there are MD functions, they are
used directly and therefore we must implicitly guarantee that they
are safe from multiple evaluation. Defining an MD function to an
MI macro breaks this promise.
ok deraadt@
Unify the MD byteswapping code as much as possible across architectures.2018-10-02T21:30:44Znaddynaddy@openbsd.org2018-10-02T21:30:44Zurn:sha1:30189709ef4dec80e8998d4b5ad83ca9d6053e24
Use inline functions instead of GNU C statement expressions, and
make them available to userland. With clues from guenther@.
ok guenther@ kettenis@
Unify and bump some of the NMBCLUSTERS defines. Some archs had it set to2018-09-14T13:58:20Zclaudioclaudio@openbsd.org2018-09-14T13:58:20Zurn:sha1:965127f80578c0400be53e4188190c636e97095a
4MB which is far too low especially when the platform is able to run MP.
New limits are, amd64 = 256M; arm64, mips64, sparc64 = 64M; alpha, arm,
hppa, i386, powerpc = 32M; m88k, sh = 8M
Still rather conservative numbers but much better than before. At least
some hangs of arm64 build boxes was caused by this.
OK kettenis@, visa@