This gets us nanoseconds instead of microseconds, which is better, and
we can do this pretty much without freaking out existing userspace,
which doesn't actually make use of the nano/micro seconds field:
zx2c4@thinkpad ~ $ cat a.c
void main()
{
puts(sizeof(struct timeval) == sizeof(struct timespec) ? "success" : "failure");
}
zx2c4@thinkpad ~ $ gcc a.c -m64 && ./a.out
success
zx2c4@thinkpad ~ $ gcc a.c -m32 && ./a.out
success
This doesn't solve y2038 problem, but timespec64 isn't yet a thing in
userspace.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
One types:
for (i = 0 ...
So one should also type:
for_each_obj (obj ...
But the upstream kernel style guidelines are insane, and so we must
instead do:
for_each_obj(obj ...
Ugly, but one must choose his battles wisely.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
DaveM suggests we do in fact do this. Others on the same thread weren't
happy about the length of the proposed message, so we also give a bit of
a less dramatic warning.
This reverts commit a2cc976a3b572cf308cc2d97c080eacac60416fe.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Maybe an attacker on the system could use the infoleak in /proc to gauge
how long a wg(8) process takes to complete and determine the number of
leading zeros. This is somewhat ridiculous, but it's possible somebody
somewhere might at somepoint care in the future, so alright.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
They have no permissions, so we're probably better off just creating a
socket file with the umask set, as we do in BSD.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld