Paul Irofti <[email protected]> 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?
yes, because the "old code" remains. It's the system calls we use today.
