On 2012-04-01 09.05, Theo de Raadt wrote:
> The epoch isn't far that away and we need to prepare OpenBSD for it.
> 
> I had a little free time, so I wrote a diff to simulate the behaviour
> so that we can test how parts of OpenBSD cope with it.

May I suggest a more versatile and flexible approach to the problem?

Here's the man page diff:

--- /dev/null   Sun Apr  1 18:25:35 2012
+++ lib/libc/sys/getendofdays.2 Sun Apr  1 18:24:23 2012
@@ -0,0 +1,139 @@
+.\"    $OpenBSD: getendofdays.2,v 1.00 2012/04/01 21:00:59 hcamping Exp $
+.\"
+.\" Copyright (c) 1980, 1991, 1993, 13 b'ak'tun
+.\"    The Regents of the University of California.  All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this
software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"     @(#)getendofdays.2     8.2 (Berkeley) 4/1/2012
+.\"
+.Dd $Mdocdate: Apr 1 2012 $
+.Dt getendofdays 2
+.Os
+.Sh NAME
+.Nm getendofdays ,
+.Nm setendofdays
+.Nd get/set timestamp of current end of times
+.Sh SYNOPSIS
+.Fd #include <sys/time.h>
+.Ft int
+.Fn getendofdays "struct timeval *raptp" "struct timeval *repentp"
+.Ft int
+.Fn setendofdays "const struct timeval *raptp" "const struct timeval
*repentp"
+.Sh DESCRIPTION
+.Bf -symbolic
+Note: timezone is no longer used; this information is kept outside
+the kernel. In any event, it won't be needed after.
+.Ef
+.Pp
+The system's notion of when the end of days, also known as EOE (End of
Epoch),
+occurs, as well as at what time the system will automatically be shut
down in
+order to preserve itself is obtained with the
+.Fn getendofdays
+call, and set with the
+.Fn setendofdays
+call.
+The time is expressed in seconds and microseconds
+since midnight (0 hour), January 1, 1970.
+The resolution of the system clock is hardware dependent, and the time
+may be updated continuously or in
+.Dq ticks .
+If
+.Fa raptp
+is
+.Dv NULL ,
+the associated time
+information will not be returned, or the default EOE of Jan 19, 2038
+will be set, respectively.
+.Pp
+If
+.Fa repentp
+is
+.Dv NULL ,
+the associated time
+information will not be returned, and there will be no repentive system
+shutdown performed (not recommended).
+.Pp
+The structure pointed to by
+.Fa raptp
+and
+.Fa repentp
+is defined in
+.Aq Pa sys/time.h
+as:
+.Bd -literal
+struct timeval {
+       long    tv_sec;         /* seconds since Jan. 1, 1970 */
+       long    tv_usec;        /* and microseconds */
+};
+
+.Ed
+.Pp
+Only the superuser may set the end of days.
+If the system securelevel is greater than 1 (see
+.Xr init 8 ) ,
+the end of days may only be advanced.
+This limitation is imposed to prevent a malicious superuser
+from setting arbitrary ends of days.
+.Sh RETURN VALUES
+A 0 return value indicates that the call succeeded and that the end is
nigh.
+A \-1 return value indicates an error occurred, and in this
+case an error code is stored into the global variable
+.Va errno .
+.Sh ERRORS
+The following error codes may be set in
+.Va errno :
+.Bl -tag -width [EFAULT]
+.It Bq Er EFAULT
+An argument address referenced invalid memory.
+.It Bq Er EPERM
+A user other than the superuser attempted to set the end of days.
+.It Bq Er EBUSY
+The end of days is already in progress.
+.It Bq Er ETIMEDOUT
+The end of days was set to a time which has passed, and no end of days
event
+was received. A new end of days must be set.
+.El
+.Sh SEE ALSO
+.Xr date 1 ,
+.Xr adjtime 2 ,
+.Xr getitimer 2 ,
+.Xr ctime 3 ,
+.Xr kill 2 ,
+.Xr shutdown 8
+.Sh HISTORY
+The
+.Fn getendofdays
+and
+.Fn setendofdays
+function calls appeared in August, 3114 BCE.
+.Sh CAVEATS
+Setting the end of days with
+.Fn setendofdays
+is dangerous; if possible set a time far into the future.
+Time warps and black holes can cause programs to malfunction in unexpected
+ways.
+If the end of days must be set, consider rebooting the machine for safety.
+The end of days kernel code is untested.


Regards,
/Benny

-- 
internetlabbet.se     / work:   +46 8 551 124 80      / "Words must
Benny Lofgren        /  mobile: +46 70 718 11 90     /   be weighed,
                    /   fax:    +46 8 551 124 89    /    not counted."
                   /    email:  benny -at- internetlabbet.se

Reply via email to