On 2020-06-11 16:54, Mark Kettenis wrote:
Date: Thu, 11 Jun 2020 16:27:03 +0300
From: Paul Irofti <p...@irofti.net>
On Thu, Jun 11, 2020 at 02:49:54PM +0200, Marc Espie wrote:
On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
On 2020-06-11 02:46, Christian Weisgerber wrote:
Paul Irofti:
This iteration of the diff adds bounds checking for tk_user and moves
the usertc.c stub to every arch in libc as recommanded by deraadt@.
It also fixes a gettimeofday issue reported by cheloha@ and tb@.
Additionally, it changes struct timekeep in an incompatible way. ;-)
A userland built before the addition of tk_nclocks is very unhappy
with a kernel built afterwards. There is no way to compile across
this. You have to (U)pgrade from boot media to install a ftp.openbsd.org
userland, and then you can re-compile with the new diff.
I have not seen this problem and have not built a snapshot to update or go
back. What do you mean by very unhappy? Can you show me the exact steps you
have done?
Should we already bump major while the diff matures?
I am not a fan of this. I don't like bumping something before it is actually
used. It is like an errata before a release.
So what if we end at version 200 ?
we've got a full uint32_t for crying out loud, you're not going to run out
of numbers.
Besides, it's something that's entirely invisible to users, even more so
than library major/minors.
This is not about the range available to us.
If I bump then I will have to also add checks for the revision.
Otherwise what is the point of the bump? And then what? Keep old and
new code around for both revisions? And then, if this endless mail
thread is ever going to be added to the OpenBSD tree, it will contain
workarounds for something that was never in the tree to begin with.
Yeah, you do check for the revision, if it's the same, then you use
the timecounter. If it's not, you revert to the syscall.
End of story.
Right now, you can't even bump it if you need, because there is no code
that checks it in the libc, thus is you tweak kernel parts, things *will*
break.
You'd better have the version check in libc before you even consider
committing this!
Paul, that tk_nclocks addition isn't useful. You need to do the
bounds checking against the number of clocks you have implemented in
libc. How many clocks the kernel has implemented doesn't matter.
I agree. But I am not checking how many clocks the kernel is
implementing, but how many it is exposing to the user.
What you are saying is that we could be in a situation where the kernel
might expose 3 clocks but we only have 2 entries in libc? Why would we
get to that point? When someone changes the clock in the kernel, that
means it is also changed in libc. I don't think we can decouple the two
parts. Right?
