> Date: Thu, 11 Jun 2020 14:49:54 +0200 > From: Marc Espie <es...@nerim.net> > > 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!
Yup.
