Re: Making time_t deal with the coming epoch
err. this is a april fool right, guys?
:-)
On Sun, Apr 1, 2012 at 1:13 PM, Nicholas Marriott
wrote:
> Can I make it wake up again automatically three days later?
>
>
> On Sun, Apr 01, 2012 at 06:35:08PM +0200, Benny Lofgren wrote:
>> 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
>> +.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 {
>> + longtv_sec; /* seconds since Jan. 1, 1970 */
>> + longtv_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 e
Re: npppd_arp.h missing in the tree
Hi, On Sat, 31 Mar 2012 16:30:37 +0200 mxb wrote: > looks like npppd_arp.h is missing in the tree. > > Is it in purpose or just a miss? There are npppd_arp.[ch] in IIJ(upstream and company I work for)'s local tree. But they are work-in-progress. So they should be deleted in our tree. --yasuoka
Invitación a Youzzers.com
Buenos dCas, tech@openbsd.org. Messi 10 desea invitarle a unirse a Youzzers. Para inscribirse o visitar Youzzers, cliquez ici Youzzers - La red social que protege su informaciC3n Atentamente
Re: Making time_t deal with the coming epoch
Can I make it wake up again automatically three days later?
On Sun, Apr 01, 2012 at 06:35:08PM +0200, Benny Lofgren wrote:
> 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
> +.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 {
> + longtv_sec; /* seconds since Jan. 1, 1970 */
> + longtv_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 a
Re: aml: Fix integer types to be unsigned
On Sun, Apr 01, 2012 at 01:54:10PM +0300, Paul Irofti wrote: > [--snip-some-of-the-gyping-from-my-initial-diff--] > > case AML_OBJTYPE_STRING: > > - if (ival == -1) > > + if (ival == (uint64_t)-1) > > This is what I tried first as well. But this cast fails on my x61s where > ival is set to a 32-bit -1. I'd like to stress one thing that I did not make clear previously. If youy cast the lhs to (signed), it is a width reducing conversion, these are done by just truncating the bits. This has the effect that ANY value (signed) 0x will be equal to -1. That is certainly not what you want. The general lesson is: alway be very suspicious of width reducing conversions. -Otto > > > ival = strlen((const char *)bval); > > lhs->length = ival; > > lhs->v_string = (char *)acpi_os_malloc(ival+1);
Re: Making time_t deal with the coming epoch
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
+.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 {
+ longtv_sec; /* seconds since Jan. 1, 1970 */
+ longtv_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 CAVE
Re: Making time_t deal with the coming epoch
runs ok on amd64.
Would test more, but it's gotten really dark for no apparent
reason. Need to check that out before someone gets hurt.
On Sun, Apr 01, 2012 at 01:05:05AM -0600, 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.
>
> Index: sys/sysctl.h
> ===
> RCS file: /cvs/src/sys/sys/sysctl.h,v
> retrieving revision 1.121
> diff -u -p -u -r1.121 sysctl.h
> --- sys/sysctl.h 23 Mar 2012 15:51:26 - 1.121
> +++ sys/sysctl.h 1 Apr 2012 04:27:45 -
> @@ -184,7 +184,8 @@ struct ctlname {
> #define KERN_NETLIVELOCKS 76 /* int: number of network
> livelocks */
> #define KERN_POOL_DEBUG 77 /* int: enable pool_debug */
> #define KERN_PROC_CWD 78 /* node: proc cwd */
> -#define KERN_MAXID 79 /* number of valid kern ids */
> +#define KERN_EMULATEMAYANPROPHESY 79/* int: prevent the first epoch
> */
> +#define KERN_MAXID 80 /* number of valid kern ids */
>
> #define CTL_KERN_NAMES { \
> { 0, 0 }, \
> @@ -266,6 +267,7 @@ struct ctlname {
> { "netlivelocks", CTLTYPE_INT }, \
> { "pool_debug", CTLTYPE_INT }, \
> { "proc_cwd", CTLTYPE_NODE }, \
> + { "emulatemayanprophesy", CTLTYPE_INT }, \
> }
>
> /*
> Index: sys/time.h
> ===
> RCS file: /cvs/src/sys/sys/time.h,v
> retrieving revision 1.26
> diff -u -p -u -r1.26 time.h
> --- sys/time.h27 Nov 2009 19:45:54 - 1.26
> +++ sys/time.h1 Apr 2012 06:32:21 -
> @@ -270,6 +270,17 @@ extern volatile time_t time_second; /* S
> extern volatile time_t time_uptime; /* Seconds since reboot. */
>
> /*
> + * Wikipedia: "The current (13th) b'ak'tun will end, or be completed, on
> + * 13.0.0.0.0 (December 21, 2012 using the GMT correlation". GMT or
> + * Mexico/General? What's 6 hours between Mayans friends.. let's follow
> + * 'Mexican time' rules. You might get 6 more hours of reading your
> + * mail, but don't count on it.
> + */
> +#define END_13BAKTUN 1356069600
> +extern int emulatemayanprophecy; /* End time before the Mayans do */
> +
> +
> +/*
> * Functions for looking at our clock: [get]{bin,nano,micro}[up]time()
> *
> * Functions without the "get" prefix returns the best timestamp
> Index: kern/kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.73
> diff -u -p -u -r1.73 kern_clock.c
> --- kern/kern_clock.c 23 Mar 2012 15:51:26 - 1.73
> +++ kern/kern_clock.c 1 Apr 2012 06:21:53 -
> @@ -108,6 +108,8 @@ int psratio;/* ratio: prof
> / stat */
>
> long cp_time[CPUSTATES];
>
> +int emulatemayanprophecy; /* sysctl: stop time at end of 13th b'ak'tun */
> +
> #ifndef __HAVE_TIMECOUNTER
> int tickfix, tickfixinterval; /* used if tick not really integral */
> static int tickfixcnt; /* accumulated fractional error
> */
> @@ -292,8 +294,16 @@ hardclock(struct clockframe *frame)
>
> BUMPTIME(&time, delta);
> BUMPTIME(&mono_time, delta);
> - time_second = time.tv_sec;
> - time_uptime = mono_time.tv_sec;
> + if (emulatemayanprophecy) {
> + if (time.tv_sec < END_13BAKTUN) {
> + time_second = time.tv_sec;
> + time_uptime = mono_time.tv_sec;
> + }
> + } else {
> + time_second = time.tv_sec;
> + time_uptime = mono_time.tv_sec;
> + }
> +
> #else
> tc_ticktock();
> #endif
> Index: kern/kern_sysctl.c
> ===
> RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
> retrieving revision 1.218
> diff -u -p -u -r1.218 kern_sysctl.c
> --- kern/kern_sysctl.c28 Mar 2012 16:01:30 - 1.218
> +++ kern/kern_sysctl.c1 Apr 2012 04:27:45 -
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -607,6 +608,9 @@ kern_sysctl(int *name, u_int namelen, vo
> pool_reclaim_all();
> return (error);
> }
> + case KERN_EMULATEMAYANPROPHESY:
> + return (sysctl_int(oldp, oldlenp, newp, newlen,
> + &emulatemayanprophecy));
> default:
> return (EOPNOTSUPP);
> }
> Index: kern/kern_tc.c
> ===
> RCS file: /cvs/src/sys/kern/kern_tc.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 kern_tc.c
> --- kern/kern_tc.c24 Sep 2010 07:29:30 - 1.16
> +++ kern/kern_tc.c1 Apr 2012 06:49:06 -
> @@
Re: aml: Fix integer types to be unsigned
> Date: Sun, 1 Apr 2012 13:54:10 +0300
> From: Paul Irofti
>
> [--snip-some-of-the-gyping-from-my-initial-diff--]
Not really gyped. Already had some of it in my tree from when I
looked at the arithnmetic diff. It was just that your casting
mistakes made me realize what the right way to go was ;).
> > case AML_OBJTYPE_STRING:
> > - if (ival == -1)
> > + if (ival == (uint64_t)-1)
>
> This is what I tried first as well. But this cast fails on my x61s where
> ival is set to a 32-bit -1.
Well, the real bug is that ival gets set to "32-bit -1" (by which you
mean 0x I presume). That should never happen. May very well
be a bug that you introduced in your diff because:
> Index: dev/acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.193
> diff -u -p -r1.193 dsdt.c
> --- dev/acpi/dsdt.c 15 Mar 2012 18:36:53 - 1.193
> +++ dev/acpi/dsdt.c 30 Mar 2012 22:45:15 -
> @@ -1451,11 +1448,11 @@ static char osstring[] = "Macrosift Wind
> struct aml_defval {
> const char *name;
> int type;
> - int64_t ival;
> + u_int64_t ival;
> const void *bval;
> struct aml_value**gval;
> } aml_defobj[] = {
> - { "_OS_", AML_OBJTYPE_STRING, -1, osstring },
> + { "_OS_", AML_OBJTYPE_STRING, (unsigned)-1, osstring },
> { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
> { "_GL", AML_OBJTYPE_MUTEX, 1, NULL, &aml_global_lock },
> { "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },
...the (unsigned) cast you added there will give you one!
Re: aml: Fix integer types to be unsigned
[--snip-some-of-the-gyping-from-my-initial-diff--] > case AML_OBJTYPE_STRING: > - if (ival == -1) > + if (ival == (uint64_t)-1) This is what I tried first as well. But this cast fails on my x61s where ival is set to a 32-bit -1. > ival = strlen((const char *)bval); > lhs->length = ival; > lhs->v_string = (char *)acpi_os_malloc(ival+1);
Re: aml: Fix integer types to be unsigned
> From: Jordan Hargrave
> Date: Sun, 1 Apr 2012 08:13:13 +
>
> you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
> which would be 0xff not 0x... if using uint64.
No, that one is fine, at least on machines where char is signed. For
AMLOP_ONES, opcode will be 0xff. The cast to (signed) char turns this
into -1. The the implicit cast to either int64_t or uint64_t turns
this into a 64-bit all-ones bit pattern (0x...).
> amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to return
> AML_ONES or AML_TRUE
Made me look at the aml_match() function. It is a bit weird, since
all its arguments, even the ones representing AML integers, are int.
Using int as a return value here isn't a real problem. The -1 will be
correctly converted into a 64-bit all-ones bit patter when converted
to uint64_t by the caller. Might be worth making this explicit,
although widening the return type of functions to 64-bit might have a
performance penalty on 32-bit platforms.
Anyway, below is what I'm running now. Doesn't seem to affect things
on my x220 running amd64.
Index: amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.39
diff -u -p -r1.39 amltypes.h
--- amltypes.h 15 Oct 2010 20:25:04 - 1.39
+++ amltypes.h 1 Apr 2012 09:42:15 -
@@ -263,7 +263,7 @@ struct aml_value {
int stack;
struct aml_node *node;
union {
- int64_t vinteger;
+ uint64_tvinteger;
char*vstring;
u_int8_t*vbuffer;
struct aml_value **vpackage;
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.193
diff -u -p -r1.193 dsdt.c
--- dsdt.c 15 Mar 2012 18:36:53 - 1.193
+++ dsdt.c 1 Apr 2012 09:42:17 -
@@ -56,16 +56,16 @@ struct aml_scope*aml_load(struct acpi_s
void aml_copyvalue(struct aml_value *, struct aml_value *);
void aml_setvalue(struct aml_scope *, struct aml_value *,
- struct aml_value *, int64_t);
+ struct aml_value *, uint64_t);
void aml_freevalue(struct aml_value *);
-struct aml_value *aml_allocvalue(int, int64_t, const void *);
-struct aml_value *_aml_setvalue(struct aml_value *, int, int64_t,
+struct aml_value *aml_allocvalue(int, uint64_t, const void *);
+struct aml_value *_aml_setvalue(struct aml_value *, int, uint64_t,
const void *);
-u_int64_t aml_convradix(u_int64_t, int, int);
-u_int64_t aml_evalexpr(u_int64_t, u_int64_t, int);
-intaml_lsb(u_int64_t);
-intaml_msb(u_int64_t);
+uint64_t aml_convradix(uint64_t, int, int);
+uint64_t aml_evalexpr(uint64_t, uint64_t, int);
+intaml_lsb(uint64_t);
+intaml_msb(uint64_t);
intaml_tstbit(const u_int8_t *, int);
void aml_setbit(u_int8_t *, int, int);
@@ -99,7 +99,7 @@ void acpi_stall(int);
struct aml_value *aml_callosi(struct aml_scope *, struct aml_value *);
const char *aml_getname(const char *);
-int64_taml_hextoint(const char *);
+uint64_t aml_hextoint(const char *);
void aml_dump(int, u_int8_t *);
void _aml_die(const char *fn, int line, const char *fmt,
...);
#define aml_die(x...) _aml_die(__FUNCTION__, __LINE__, x)
@@ -869,10 +869,10 @@ aml_showvalue(struct aml_value *val, int
}
#endif /* SMALL_KERNEL */
-int64_t
+uint64_t
aml_val2int(struct aml_value *rval)
{
- int64_t ival = 0;
+ uint64_t ival = 0;
if (rval == NULL) {
dnprintf(50, "null val2int\n");
@@ -895,7 +895,7 @@ aml_val2int(struct aml_value *rval)
/* Sets value into LHS: lhs must already be cleared */
struct aml_value *
-_aml_setvalue(struct aml_value *lhs, int type, int64_t ival, const void *bval)
+_aml_setvalue(struct aml_value *lhs, int type, uint64_t ival, const void *bval)
{
memset(&lhs->_, 0x0, sizeof(lhs->_));
@@ -923,7 +923,7 @@ _aml_setvalue(struct aml_value *lhs, int
memcpy(lhs->v_buffer, bval, ival);
break;
case AML_OBJTYPE_STRING:
- if (ival == -1)
+ if (ival == (uint64_t)-1)
ival = strlen((const char *)bval);
lhs->length = ival;
lhs->v_string = (char *)acpi_os_malloc(ival+1);
@@ -1001,7 +1001,7 @@ aml_copyvalue(struct aml_value *lhs, str
* bval : Buffer value (action depends on type)
*/
struct aml_value *
-aml_allocvalue(int type, int64_t ival, const void *bval)
+aml_
Re: aml: Fix integer types to be unsigned
On Sun, Apr 01, 2012 at 08:13:13AM +, Jordan Hargrave wrote: >you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast, >which would be 0xff not 0x... if using uint64. > >amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to >return AML_ONES or AML_TRUE Noted, thanks!
Re: Making time_t deal with the coming epoch
Okay pirofti@
Re: login_yubikey does not accept user.name
2012/4/1 Theo de Raadt :
> You should really re-do that so that the login name cannot start or
> end with a '.'
Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 - 1.4
+++ login_yubikey.c 1 Apr 2012 08:37:07 -
@@ -165,10 +165,15 @@
static int
clean_string(const char *s)
{
+ int nlim, n = 0;
+
+ nlim = strlen(s) - 1;
while (*s) {
- if (!isalnum(*s) && *s != '-' && *s != '_')
+ if (!isalnum(*s) && *s != '-' && *s != '_' &&
+ !(*s == '.' && !(n == 0 || n == nlim)))
return (0);
++s;
+ n++;
}
return (1);
}
Re: aml: Fix integer types to be unsigned
you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
which would be 0xff not 0x... if using uint64.
amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to return
AML_ONES or AML_TRUE
> Date: Sun, 1 Apr 2012 10:45:55 +0300
> From: p...@irofti.net
> To: o...@drijf.net
> CC: tech@openbsd.org; kette...@openbsd.org; chas...@skynet.be;
jor...@openbsd.org
> Subject: Re: aml: Fix integer types to be unsigned
>
> On Sat, Mar 31, 2012 at 05:33:33PM +0200, Otto Moerbeek wrote:
> > On Sat, Mar 31, 2012 at 01:47:18AM +0300, Paul Irofti wrote:
> >
> > > After the report from a few weeks ago I went ahead and fixed most (if
> > > not all) of the signed integer usages in the AML parser.
> > >
> > > Please have a look at this diff, test it thoroughly and comment/okay
it.
> >
> > Some comments inline.
> >
> > > +_aml_setvalue(struct aml_value *lhs, int type, u_int64_t ival, const
void *bval)
> > > {
> > > memset(&lhs->_, 0x0, sizeof(lhs->_));
> > >
> > > @@ -923,7 +920,7 @@ _aml_setvalue(struct aml_value *lhs, int
> > > memcpy(lhs->v_buffer, bval, ival);
> > > break;
> > > case AML_OBJTYPE_STRING:
> > > - if (ival == -1)
> > > + if ((signed)ival == -1)
> >
> > Very a-typical way of doing this. Better cast the constant to the
> > target type, that's the comon idiom. (signed) is a shorthand for
> > (signed int) and not (the signed variant of the type). It is very
> > uncommon to use it.
>
> Yes, I had some issues with casting on the other side (which is what I
> tried first). Yes, I know now, that (signed) expands to (signed int).
> Well I think I knew that in the passed but the brain cells holding that
> information must've quit and moved on to a smarter brain.
>
> So the solution, I think, will be to check against (0x..ff)
> constants and stop casting.
>
> The problem here was that I got values in ival that were
> 32-bit and also 64-bit versions of -1.
Re: aml: Fix integer types to be unsigned
On Sat, Mar 31, 2012 at 05:33:33PM +0200, Otto Moerbeek wrote:
> On Sat, Mar 31, 2012 at 01:47:18AM +0300, Paul Irofti wrote:
>
> > After the report from a few weeks ago I went ahead and fixed most (if
> > not all) of the signed integer usages in the AML parser.
> >
> > Please have a look at this diff, test it thoroughly and comment/okay it.
>
> Some comments inline.
>
> > +_aml_setvalue(struct aml_value *lhs, int type, u_int64_t ival, const void
> > *bval)
> > {
> > memset(&lhs->_, 0x0, sizeof(lhs->_));
> >
> > @@ -923,7 +920,7 @@ _aml_setvalue(struct aml_value *lhs, int
> > memcpy(lhs->v_buffer, bval, ival);
> > break;
> > case AML_OBJTYPE_STRING:
> > - if (ival == -1)
> > + if ((signed)ival == -1)
>
> Very a-typical way of doing this. Better cast the constant to the
> target type, that's the comon idiom. (signed) is a shorthand for
> (signed int) and not (the signed variant of the type). It is very
> uncommon to use it.
Yes, I had some issues with casting on the other side (which is what I
tried first). Yes, I know now, that (signed) expands to (signed int).
Well I think I knew that in the passed but the brain cells holding that
information must've quit and moved on to a smarter brain.
So the solution, I think, will be to check against (0x..ff)
constants and stop casting.
The problem here was that I got values in ival that were
32-bit and also 64-bit versions of -1.
Re: aml: Fix integer types to be unsigned
On Sat, Mar 31, 2012 at 12:18:27PM +0200, Mark Kettenis wrote:
> > Date: Sat, 31 Mar 2012 01:47:18 +0300
> > From: Paul Irofti
> >
> > After the report from a few weeks ago I went ahead and fixed most (if
> > not all) of the signed integer usages in the AML parser.
> >
> > Please have a look at this diff, test it thoroughly and comment/okay it.
>
> So you ran into the same issue that -1 has this special meaning where
> I decided to go for a minimal fix instead. The C integer promotion
> rules always confuse me (I think otto@ is the only person in the world
> who actually understands them). The way you sprinkled (signed) and
> (unsigned) in the code makes me very suspicious since I don't think it
> does what you think it does. Now using -1 as a magic value for an
> unsigned type isn't entirely uncommon, and the "traditional" way to
> handle this has always been to cast the -1 constant to the appropriate
> type. So...
Yes, the casting was bad and I fixed that in my tree. I just need to add
some more type changes (aml_value!length) and I'll send a new diff.
>
> > Index: dev/acpi/dsdt.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> > retrieving revision 1.193
> > diff -u -p -r1.193 dsdt.c
> > --- dev/acpi/dsdt.c 15 Mar 2012 18:36:53 - 1.193
> > +++ dev/acpi/dsdt.c 30 Mar 2012 22:45:15 -
> > @@ -895,7 +892,7 @@ aml_val2int(struct aml_value *rval)
> >
> > /* Sets value into LHS: lhs must already be cleared */
> > struct aml_value *
> > -_aml_setvalue(struct aml_value *lhs, int type, int64_t ival, const void
> > *bval)
> > +_aml_setvalue(struct aml_value *lhs, int type, u_int64_t ival, const void
> > *bval)
> > {
> > memset(&lhs->_, 0x0, sizeof(lhs->_));
> >
> > @@ -923,7 +920,7 @@ _aml_setvalue(struct aml_value *lhs, int
> > memcpy(lhs->v_buffer, bval, ival);
> > break;
> > case AML_OBJTYPE_STRING:
> > - if (ival == -1)
> > + if ((signed)ival == -1)
>
> + if (ival == (u_int64_t)-1)
>
> > ival = strlen((const char *)bval);
> > lhs->length = ival;
> > lhs->v_string = (char *)acpi_os_malloc(ival+1);
> > @@ -1451,11 +1448,11 @@ static char osstring[] = "Macrosift Wind
> > struct aml_defval {
> > const char *name;
> > int type;
> > - int64_t ival;
> > + u_int64_t ival;
> > const void *bval;
> > struct aml_value**gval;
> > } aml_defobj[] = {
> > - { "_OS_", AML_OBJTYPE_STRING, -1, osstring },
> > + { "_OS_", AML_OBJTYPE_STRING, (unsigned)-1, osstring },
>
> and there should be no need to add a cast here.
Making time_t deal with the coming epoch
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.
Index: sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.121
diff -u -p -u -r1.121 sysctl.h
--- sys/sysctl.h23 Mar 2012 15:51:26 - 1.121
+++ sys/sysctl.h1 Apr 2012 04:27:45 -
@@ -184,7 +184,8 @@ struct ctlname {
#defineKERN_NETLIVELOCKS 76 /* int: number of network
livelocks */
#defineKERN_POOL_DEBUG 77 /* int: enable pool_debug */
#defineKERN_PROC_CWD 78 /* node: proc cwd */
-#defineKERN_MAXID 79 /* number of valid kern ids */
+#defineKERN_EMULATEMAYANPROPHESY 79/* int: prevent the first epoch
*/
+#defineKERN_MAXID 80 /* number of valid kern ids */
#defineCTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -266,6 +267,7 @@ struct ctlname {
{ "netlivelocks", CTLTYPE_INT }, \
{ "pool_debug", CTLTYPE_INT }, \
{ "proc_cwd", CTLTYPE_NODE }, \
+ { "emulatemayanprophesy", CTLTYPE_INT }, \
}
/*
Index: sys/time.h
===
RCS file: /cvs/src/sys/sys/time.h,v
retrieving revision 1.26
diff -u -p -u -r1.26 time.h
--- sys/time.h 27 Nov 2009 19:45:54 - 1.26
+++ sys/time.h 1 Apr 2012 06:32:21 -
@@ -270,6 +270,17 @@ extern volatile time_t time_second;/* S
extern volatile time_t time_uptime;/* Seconds since reboot. */
/*
+ * Wikipedia: "The current (13th) b'ak'tun will end, or be completed, on
+ * 13.0.0.0.0 (December 21, 2012 using the GMT correlation". GMT or
+ * Mexico/General? What's 6 hours between Mayans friends.. let's follow
+ * 'Mexican time' rules. You might get 6 more hours of reading your
+ * mail, but don't count on it.
+ */
+#define END_13BAKTUN 1356069600
+extern int emulatemayanprophecy; /* End time before the Mayans do */
+
+
+/*
* Functions for looking at our clock: [get]{bin,nano,micro}[up]time()
*
* Functions without the "get" prefix returns the best timestamp
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.73
diff -u -p -u -r1.73 kern_clock.c
--- kern/kern_clock.c 23 Mar 2012 15:51:26 - 1.73
+++ kern/kern_clock.c 1 Apr 2012 06:21:53 -
@@ -108,6 +108,8 @@ int psratio;/* ratio: prof / stat */
long cp_time[CPUSTATES];
+intemulatemayanprophecy; /* sysctl: stop time at end of 13th b'ak'tun */
+
#ifndef __HAVE_TIMECOUNTER
inttickfix, tickfixinterval; /* used if tick not really integral */
static int tickfixcnt; /* accumulated fractional error */
@@ -292,8 +294,16 @@ hardclock(struct clockframe *frame)
BUMPTIME(&time, delta);
BUMPTIME(&mono_time, delta);
- time_second = time.tv_sec;
- time_uptime = mono_time.tv_sec;
+ if (emulatemayanprophecy) {
+ if (time.tv_sec < END_13BAKTUN) {
+ time_second = time.tv_sec;
+ time_uptime = mono_time.tv_sec;
+ }
+ } else {
+ time_second = time.tv_sec;
+ time_uptime = mono_time.tv_sec;
+ }
+
#else
tc_ticktock();
#endif
Index: kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.218
diff -u -p -u -r1.218 kern_sysctl.c
--- kern/kern_sysctl.c 28 Mar 2012 16:01:30 - 1.218
+++ kern/kern_sysctl.c 1 Apr 2012 04:27:45 -
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -607,6 +608,9 @@ kern_sysctl(int *name, u_int namelen, vo
pool_reclaim_all();
return (error);
}
+ case KERN_EMULATEMAYANPROPHESY:
+ return (sysctl_int(oldp, oldlenp, newp, newlen,
+ &emulatemayanprophecy));
default:
return (EOPNOTSUPP);
}
Index: kern/kern_tc.c
===
RCS file: /cvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 kern_tc.c
--- kern/kern_tc.c 24 Sep 2010 07:29:30 - 1.16
+++ kern/kern_tc.c 1 Apr 2012 06:49:06 -
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,14 @@ tc_windup(void)
i = 2;
for (; i > 0; i--)
ntp_update_second(&th->th_adjustment, &bt.sec);
+
+ if (emulatemayanprophecy) {
+ struct timeval tv;
+
+ bintime2timeval(&bt, &tv);
+ if (tv.tv_sec >= END_
