Re: [PATCH] Add -d flag to du(1)
On 9/16/2014 4:00 PM, Ingo Schwarze wrote: Hi, On 9/15/2014 10:58 PM, William Orr wrote: This diff adds a flag to du(1) to limit the depth of results that are displayed to the user. The semantics are equivalent to FreeBSD's, where it is mutually exclusive with -a and -s, and du -d 0 is equivalent to du -s. Thoughts? I think it's a bad idea and i'd prefer to not have this flag. It complicates the manual and code for almost no gain. Unix tools are supposed to do one thing each, and do it well. Selecting files out of a file hierarchy and providing options for selection is the task of find(1), not du(1). Doing what you want is trivial combining find and -exec du, or find | xargs du. What next? du --flags --group --name --user? However: * FreeBSD has it since 1996 (John-Mark Gurney is to blame for the bloat) * GNU coreutils has --max-depth since 1997 (Jim Meyering is to blame) * consequently, DragonFly has it forever (since 2003) * NetBSD has it since 2006 (Elad Efrat committed) * GNU coreutils has -d as an alias for --max-depth it since 2010 * illumos (and OpenSolaris before it) has different semantics: illumos du -d is the same as BSD du -x That may be a Sun invention, i have no idea. * Neither SysV nor 4.4BSD had a -d option. * POSIX does not have it. Even though it is not standardized, it seems so widespread by now that i think we better follow, given that it's not actively harmful and the bloat is relatively little: In my version of the patch, the actual prtout() tests become *simpler* instead of more complicated. I polished the diff in the following ways: * The meaning of the depth argument is much easier to understand when we explicitly say that -d 0 is the same as -s. * "Grand total" is used in two different senses; downgrade the smaller one to just "total" to reduce potential for confusion. * Mention that -d is a POSIX extension. * Correct HISTORY: du is v1, not v3; and add missing history of options. We are adding a new option, so it's a good time to do that. HISTORY can be checked here: http://mdocml.bsd.lv/cgi-bin/man.cgi/history/man1/du.1 * Simplify option handling: Delete two *flag variables instead of adding one. * Do not mix declarations and initialization. * Sort options in getopt(3). * Detect option clashes right away. That's better because it also catches duplicate -d options. * No need to cast the strtonum(3) return value. * Avoid duplicate "invalid" in error message. * Avoid a few excessively long lines. OK? Ingo This seems to work the same in all of my test cases, and is *much* better than my original patch. Thanks for the polish! P.S. William, whitespace was mangled in your patch. Serves me right for hurriedly copying the patch from a putty session when I realized I forgot to update usage().
Re: make top combine cpu lines by default if you have a lot of cpus
On 09/17/14 07:44, Alexander Hall wrote:
On September 17, 2014 3:54:34 AM CEST, David Gwynne wrote:
not yet. we could make -1 toggle combine_cpu, or have something like -1
and -N for combined and "N" cpus displayed?
If we want it, I'm in strong favor for the latter. Toggles are horrible, IMO.
If we don't consider needing it, it might make sense not to compress the CPU
list for non-interactive use.
I didn't realize top had toggles already, so never mind...
/Alexander
/Alexander
On 16 Sep 2014, at 11:08 pm, Alexander Hall wrote:
On September 16, 2014 2:11:28 PM CEST, Mark Kettenis
wrote:
Date: Tue, 16 Sep 2014 21:51:00 +1000
From: David Gwynne
if you have more than 8 cpus, combine the cpu lines by default.
Just curious, is there a command line argument to expand the list?
/Alexander
ok?
8 seems a reasonable number
ok kettenis@
Index: machine.c
===
RCS file: /cvs/src/usr.bin/top/machine.c,v
retrieving revision 1.78
diff -u -p -r1.78 machine.c
--- machine.c 4 Jul 2014 05:58:31 - 1.78
+++ machine.c 16 Sep 2014 11:46:41 -
@@ -141,14 +141,26 @@ int ncpu;
unsigned intmaxslp;
int
-machine_init(struct statics *statics)
+getncpu(void)
{
+ int mib[] = { CTL_HW, HW_NCPU };
+ int ncpu;
size_t size = sizeof(ncpu);
- int mib[2], pagesize, cpu;
- mib[0] = CTL_HW;
- mib[1] = HW_NCPU;
- if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
+ if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
+ &ncpu, &size, NULL, 0) == -1)
+ return (-1);
+
+ return (ncpu);
+}
+
+int
+machine_init(struct statics *statics)
+{
+ int pagesize, cpu;
+
+ ncpu = getncpu();
+ if (ncpu == -1)
return (-1);
cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
if (cpu_states == NULL)
Index: machine.h
===
RCS file: /cvs/src/usr.bin/top/machine.h,v
retrieving revision 1.17
diff -u -p -r1.17 machine.h
--- machine.h 5 Jun 2012 18:52:53 - 1.17
+++ machine.h 16 Sep 2014 11:46:41 -
@@ -93,3 +93,5 @@ extern char*format_next_process(cadd
extern uid_tproc_owner(pid_t);
extern struct kinfo_proc*getprocs(int, int, int *);
+
+intgetncpu(void);
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving revision 1.81
diff -u -p -r1.81 top.c
--- top.c 7 Apr 2014 15:49:22 - 1.81
+++ top.c 16 Sep 2014 11:46:41 -
@@ -250,6 +250,13 @@ parseargs(int ac, char **av)
}
}
+ i = getncpu();
+ if (i == -1)
+ err(1, NULL);
+
+ if (i > 8)
+ combine_cpus = 1;
+
/* get count of top processes to display (if any) */
if (optind < ac) {
if ((topn = atoiwi(av[optind])) == Invalid) {
Re: make top combine cpu lines by default if you have a lot of cpus
On September 17, 2014 3:54:34 AM CEST, David Gwynne wrote:
>not yet. we could make -1 toggle combine_cpu, or have something like -1
>and -N for combined and "N" cpus displayed?
If we want it, I'm in strong favor for the latter. Toggles are horrible, IMO.
If we don't consider needing it, it might make sense not to compress the CPU
list for non-interactive use.
/Alexander
>
>On 16 Sep 2014, at 11:08 pm, Alexander Hall wrote:
>
>>
>>
>> On September 16, 2014 2:11:28 PM CEST, Mark Kettenis
> wrote:
Date: Tue, 16 Sep 2014 21:51:00 +1000
From: David Gwynne
if you have more than 8 cpus, combine the cpu lines by default.
>>
>> Just curious, is there a command line argument to expand the list?
>>
>> /Alexander
>>
ok?
>>>
>>> 8 seems a reasonable number
>>>
>>> ok kettenis@
>>>
Index: machine.c
===
RCS file: /cvs/src/usr.bin/top/machine.c,v
retrieving revision 1.78
diff -u -p -r1.78 machine.c
--- machine.c 4 Jul 2014 05:58:31 - 1.78
+++ machine.c 16 Sep 2014 11:46:41 -
@@ -141,14 +141,26 @@ int ncpu;
unsigned int maxslp;
int
-machine_init(struct statics *statics)
+getncpu(void)
{
+ int mib[] = { CTL_HW, HW_NCPU };
+ int ncpu;
size_t size = sizeof(ncpu);
- int mib[2], pagesize, cpu;
- mib[0] = CTL_HW;
- mib[1] = HW_NCPU;
- if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
+ if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
+ &ncpu, &size, NULL, 0) == -1)
+ return (-1);
+
+ return (ncpu);
+}
+
+int
+machine_init(struct statics *statics)
+{
+ int pagesize, cpu;
+
+ ncpu = getncpu();
+ if (ncpu == -1)
return (-1);
cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
if (cpu_states == NULL)
Index: machine.h
===
RCS file: /cvs/src/usr.bin/top/machine.h,v
retrieving revision 1.17
diff -u -p -r1.17 machine.h
--- machine.h 5 Jun 2012 18:52:53 - 1.17
+++ machine.h 16 Sep 2014 11:46:41 -
@@ -93,3 +93,5 @@ extern char*format_next_process(cadd
extern uid_tproc_owner(pid_t);
extern struct kinfo_proc *getprocs(int, int, int *);
+
+int getncpu(void);
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving revision 1.81
diff -u -p -r1.81 top.c
--- top.c 7 Apr 2014 15:49:22 - 1.81
+++ top.c 16 Sep 2014 11:46:41 -
@@ -250,6 +250,13 @@ parseargs(int ac, char **av)
}
}
+ i = getncpu();
+ if (i == -1)
+ err(1, NULL);
+
+ if (i > 8)
+ combine_cpus = 1;
+
/* get count of top processes to display (if any) */
if (optind < ac) {
if ((topn = atoiwi(av[optind])) == Invalid) {
>>
Re: make top combine cpu lines by default if you have a lot of cpus
not yet. we could make -1 toggle combine_cpu, or have something like -1 and -N
for combined and "N" cpus displayed?
On 16 Sep 2014, at 11:08 pm, Alexander Hall wrote:
>
>
> On September 16, 2014 2:11:28 PM CEST, Mark Kettenis
> wrote:
>>> Date: Tue, 16 Sep 2014 21:51:00 +1000
>>> From: David Gwynne
>>>
>>> if you have more than 8 cpus, combine the cpu lines by default.
>
> Just curious, is there a command line argument to expand the list?
>
> /Alexander
>
>>>
>>> ok?
>>
>> 8 seems a reasonable number
>>
>> ok kettenis@
>>
>>> Index: machine.c
>>> ===
>>> RCS file: /cvs/src/usr.bin/top/machine.c,v
>>> retrieving revision 1.78
>>> diff -u -p -r1.78 machine.c
>>> --- machine.c 4 Jul 2014 05:58:31 - 1.78
>>> +++ machine.c 16 Sep 2014 11:46:41 -
>>> @@ -141,14 +141,26 @@ int ncpu;
>>> unsigned intmaxslp;
>>>
>>> int
>>> -machine_init(struct statics *statics)
>>> +getncpu(void)
>>> {
>>> + int mib[] = { CTL_HW, HW_NCPU };
>>> + int ncpu;
>>> size_t size = sizeof(ncpu);
>>> - int mib[2], pagesize, cpu;
>>>
>>> - mib[0] = CTL_HW;
>>> - mib[1] = HW_NCPU;
>>> - if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
>>> + if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
>>> + &ncpu, &size, NULL, 0) == -1)
>>> + return (-1);
>>> +
>>> + return (ncpu);
>>> +}
>>> +
>>> +int
>>> +machine_init(struct statics *statics)
>>> +{
>>> + int pagesize, cpu;
>>> +
>>> + ncpu = getncpu();
>>> + if (ncpu == -1)
>>> return (-1);
>>> cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
>>> if (cpu_states == NULL)
>>> Index: machine.h
>>> ===
>>> RCS file: /cvs/src/usr.bin/top/machine.h,v
>>> retrieving revision 1.17
>>> diff -u -p -r1.17 machine.h
>>> --- machine.h 5 Jun 2012 18:52:53 - 1.17
>>> +++ machine.h 16 Sep 2014 11:46:41 -
>>> @@ -93,3 +93,5 @@ extern char*format_next_process(cadd
>>> extern uid_tproc_owner(pid_t);
>>>
>>> extern struct kinfo_proc*getprocs(int, int, int *);
>>> +
>>> +intgetncpu(void);
>>> Index: top.c
>>> ===
>>> RCS file: /cvs/src/usr.bin/top/top.c,v
>>> retrieving revision 1.81
>>> diff -u -p -r1.81 top.c
>>> --- top.c 7 Apr 2014 15:49:22 - 1.81
>>> +++ top.c 16 Sep 2014 11:46:41 -
>>> @@ -250,6 +250,13 @@ parseargs(int ac, char **av)
>>> }
>>> }
>>>
>>> + i = getncpu();
>>> + if (i == -1)
>>> + err(1, NULL);
>>> +
>>> + if (i > 8)
>>> + combine_cpus = 1;
>>> +
>>> /* get count of top processes to display (if any) */
>>> if (optind < ac) {
>>> if ((topn = atoiwi(av[optind])) == Invalid) {
>>>
>>>
>
Re: Fix for POSIX conformance issue
All right! I'm not yet convenient with contributing open source projects with source changes, and I don't know yet what is the most efficient way to put effort. I assume that every part of the source tree has some developer responsibility who knows it best and is the most effective working on it, so I try to find what is best way to contribute. Example of this, as you say it is best to use first setpgid and then fix setpgrp and it is best that everyone check own part of code. I'm talking here about to get focus what to do. I'm moderate to spot bugs, security holes, and other issues so I'm thinking process that is that OK, if I write tests that poke OpenBSD to crash, or make before-clean-code to smell like sh*t, and try to NOT patch issue if it is scattered everywhere in the source tree like this. And if the issue is found single component I try to fix it. Writing tests means easily full load of new files, so what is preferred way to contribute? I also noted that regress folder structure may possible need refactoring, and the coding style is very variable there. -Matti
Re: Fix for POSIX conformance issue
I have no objection to this but I don't think the System-V setpgrp() API belongs in compat-43. We can just move it to gen/setpgrp.c. Like Ted says, we should ready the source tree first by using setpgid(). However, all the uses of setpgrp() in the tree are the equivalent of: setpgrp(0, getpid()); which could be replaced more simply by: setpgid(0, 0); - todd
Re: [PATCH] Add -d flag to du(1)
Hi, On 9/15/2014 10:58 PM, William Orr wrote: > This diff adds a flag to du(1) to limit the depth of results > that are displayed to the user. > > The semantics are equivalent to FreeBSD's, where it is mutually > exclusive with -a and -s, and du -d 0 is equivalent to du -s. > > Thoughts? I think it's a bad idea and i'd prefer to not have this flag. It complicates the manual and code for almost no gain. Unix tools are supposed to do one thing each, and do it well. Selecting files out of a file hierarchy and providing options for selection is the task of find(1), not du(1). Doing what you want is trivial combining find and -exec du, or find | xargs du. What next? du --flags --group --name --user? However: * FreeBSD has it since 1996 (John-Mark Gurney is to blame for the bloat) * GNU coreutils has --max-depth since 1997 (Jim Meyering is to blame) * consequently, DragonFly has it forever (since 2003) * NetBSD has it since 2006 (Elad Efrat committed) * GNU coreutils has -d as an alias for --max-depth it since 2010 * illumos (and OpenSolaris before it) has different semantics: illumos du -d is the same as BSD du -x That may be a Sun invention, i have no idea. * Neither SysV nor 4.4BSD had a -d option. * POSIX does not have it. Even though it is not standardized, it seems so widespread by now that i think we better follow, given that it's not actively harmful and the bloat is relatively little: In my version of the patch, the actual prtout() tests become *simpler* instead of more complicated. I polished the diff in the following ways: * The meaning of the depth argument is much easier to understand when we explicitly say that -d 0 is the same as -s. * "Grand total" is used in two different senses; downgrade the smaller one to just "total" to reduce potential for confusion. * Mention that -d is a POSIX extension. * Correct HISTORY: du is v1, not v3; and add missing history of options. We are adding a new option, so it's a good time to do that. HISTORY can be checked here: http://mdocml.bsd.lv/cgi-bin/man.cgi/history/man1/du.1 * Simplify option handling: Delete two *flag variables instead of adding one. * Do not mix declarations and initialization. * Sort options in getopt(3). * Detect option clashes right away. That's better because it also catches duplicate -d options. * No need to cast the strtonum(3) return value. * Avoid duplicate "invalid" in error message. * Avoid a few excessively long lines. OK? Ingo P.S. William, whitespace was mangled in your patch. Index: du.1 === RCS file: /cvs/src/usr.bin/du/du.1,v retrieving revision 1.31 diff -u -p -r1.31 du.1 --- du.114 Feb 2014 18:17:50 - 1.31 +++ du.116 Sep 2014 22:11:24 - @@ -38,7 +38,7 @@ .Nd display disk usage statistics .Sh SYNOPSIS .Nm du -.Op Fl a | s +.Op Fl a | s | d Ar depth .Op Fl chkrx .Op Fl H | L | P .Op Ar @@ -61,6 +61,13 @@ The options are as follows: Display an entry for each file in the file hierarchy. .It Fl c Display the grand total after all the arguments have been processed. +.It Fl d Ar depth +Display an entry for each file and directory up to +.Ar depth +levels deep; +.Fl d Cm 0 +has the same effect as +.Fl s . .It Fl H Symbolic links on the command line are followed. Symbolic links encountered in the tree traversal are not followed. @@ -83,7 +90,7 @@ Generate messages about directories that that cannot be opened, and so on. This is the default. .It Fl s -Display only the grand total for the specified files. +Display only the total for each of the specified files and directories. .It Fl x File system mount points are not traversed. .El @@ -145,7 +152,7 @@ utility is compliant with the specification. .Pp The flags -.Op Fl chP , +.Op Fl cdhP , as well as the .Ev BLOCKSIZE environment variable, @@ -158,10 +165,55 @@ the obsolete .St -xcu5 standard. .Sh HISTORY -A +The .Nm -command first appeared in -.At v3 . +utility and its +.Fl a +and +.Fl s +options first appeared in +.At v1 . +.Pp +The +.Fl r +option first appeared in +.At III +and is available since +.Ox 2.3 . +The +.Fl k +and +.Fl x +options first appeared in +.Bx 4.3 Reno +and +.Fl H +in +.Bx 4.4 . +The +.Fl c +and +.Fl L +options first appeared in the GNU fileutils; +.Fl L +and +.Fl P +are available since +.Bx 4.4 Lite1 , +.Fl c +since +.Ox 2.1 . +The +.Fl d +option first appeared in +.Fx 2.2 +and is available since +.Ox 5.7 , +.Fl h +first appeared in +.Fx 4.0 +and is available since +.Ox 2.9 . .Sh AUTHORS .An -nosplit This version of Index: du.c === RCS file: /cvs/src/usr.bin/du/du.c,v retrieving revision 1.25 diff -u -p -r1.25 du.c --- du.c20 May 2014 01:25:23 - 1.25 +++ du.c16 Sep 2014 22:11:24 - @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -59,16 +60
Re: Fix for POSIX conformance issue
On Wed, Sep 17, 2014 at 01:12, Matti Karnaattu wrote:
> Hi,
>
>
> I found that OpenBSD setpgrp is not POSIX compliant, so I write test and
> make diff to fix issue.
Very nice.
>
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/setpgrp.html
>
>
> This change removes obsolete setpgrp, and fix /usr/src where it is used.
This can be done in two parts. I definitely agree with the second
half. We should use setpgid in src. Then setpgrp can be fixed when
convenient.
> 2. grep -R /usr/src/setpgrp shows that old way is used a few times but
> skipped by preprocessor directives. can someone advice me with source
> tree and practices? As some of the code is imported from elsewhere and
> cleaning those are probably not good idea if we are not forking here.
A list of locations and why setpgrp isn't used would be helpful. Right
now, everybody has to run that grep and look at the results themselves.
> #if __POSIX_VISIBLE >= 200112 || __XPG_VISIBLE >= 420 || __BSD_VISIBLE
> Index: lib/libc/compat-43/setpgrp.c
> ===
> RCS file: /OpenBSD/src/lib/libc/compat-43/setpgrp.c,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 setpgrp.c
> --- lib/libc/compat-43/setpgrp.c8 Aug 2005 08:05:33 - 1.6
> +++ lib/libc/compat-43/setpgrp.c16 Sep 2014 21:27:32 -
> @@ -32,7 +32,7 @@
> #include
>
> int
> -setpgrp(pid_t pid, pid_t pgid)
> +setpgrp(void)
> {
> - return(setpgid(pid, pgid));
> + return(setpgid(0, 0));
> }
Should probably move this file into a different directory at this
point, since it's no longer 4.3 compat.
use bcrypt_newhash in encrypt
This doesn't change a whole lot, but I'd like to start using the new
bcrypt api where feasible and move away from the crypt wrappers.
Index: encrypt.c
===
RCS file: /cvs/src/usr.bin/encrypt/encrypt.c,v
retrieving revision 1.32
diff -u -p -r1.32 encrypt.c
--- encrypt.c 3 Sep 2014 08:26:00 - 1.32
+++ encrypt.c 16 Sep 2014 22:13:43 -
@@ -105,6 +105,14 @@ print_passwd(char *string, int operation
int pwd_gensalt(char *, int, login_cap_t *, char);
void to64(char *, u_int32_t, int n);
+ if (operation == DO_BLF) {
+ if (bcrypt_newhash(string, *(int *)extra, buffer,
+ sizeof(buffer)) != 0)
+ errx(1, "bcrypt newhash failed");
+ fputs(buffer, stdout);
+ return;
+ }
+
switch(operation) {
case DO_MAKEKEY:
/*
@@ -116,11 +124,6 @@ print_passwd(char *string, int operation
}
strlcpy(msalt, &string[8], sizeof msalt);
salt = msalt;
- break;
-
- case DO_BLF:
- strlcpy(buffer, bcrypt_gensalt(*(int *)extra), _PASSWORD_LEN);
- salt = buffer;
break;
case DO_DES:
Fix for POSIX conformance issue
Hi,
I found that OpenBSD setpgrp is not POSIX compliant, so I write test and
make diff to fix issue.
http://pubs.opengroup.org/onlinepubs/009695399/functions/setpgrp.html
This change removes obsolete setpgrp, and fix /usr/src where it is used.
I can compile userland and it works.
Work to do:
1. This is my first diff and I don't know process how to fix man page,
can someone advice me?
2. grep -R /usr/src/setpgrp shows that old way is used a few times but
skipped by preprocessor directives. can someone advice me with source
tree and practices? As some of the code is imported from elsewhere and
cleaning those are probably not good idea if we are not forking here.
Cleaning process itself is very straightforward.
3. This change break backward compatibility to old BSD code favor to
POSIX, so it would be good to inform that fix:
setpgrp(pid, pid) -> setpgid(pid, pid)
NEW FILE: regress/lib/libc/setpgrp
===
/*
* Copyright (c) 2014 Matti Karnaattu
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include
/*
* POSIX.1 have System V style setpgrp calling convention that differs
* what traditionally have been in BSD systems. POSIX.1 setpgrp takes
* no arguments and puts the calling process in its on group like
* setpgid(0, 0).
*/
int
main(void)
{
return (int)(setpgrp() != setpgid(0, 0));
}
===
Index: include/unistd.h
===
RCS file: /OpenBSD/src/include/unistd.h,v
retrieving revision 1.92
diff -u -p -u -p -r1.92 unistd.h
--- include/unistd.h1 Sep 2014 05:09:52 - 1.92
+++ include/unistd.h16 Sep 2014 21:27:31 -
@@ -427,7 +427,6 @@ int nice(int);
ssize_t readlink(const char * __restrict, char * __restrict, size_t)
__attribute__ ((__bounded__(__string__,2,3)));
int setkey(const char *);
-int setpgrp(pid_t pid, pid_t pgrp);/* obsoleted by setpgid() */
int setregid(gid_t, gid_t);
int setreuid(uid_t, uid_t);
voidswab(const void *, void *, size_t);
@@ -464,6 +463,7 @@ void*sbrk(int);
#if __POSIX_VISIBLE >= 200112 || __XPG_VISIBLE >= 420
int lockf(int, int, off_t);
+int setpgrp(void);
#endif
#if __POSIX_VISIBLE >= 200112 || __XPG_VISIBLE >= 420 || __BSD_VISIBLE
Index: lib/libc/compat-43/setpgrp.c
===
RCS file: /OpenBSD/src/lib/libc/compat-43/setpgrp.c,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 setpgrp.c
--- lib/libc/compat-43/setpgrp.c8 Aug 2005 08:05:33 - 1.6
+++ lib/libc/compat-43/setpgrp.c16 Sep 2014 21:27:32 -
@@ -32,7 +32,7 @@
#include
int
-setpgrp(pid_t pid, pid_t pgid)
+setpgrp(void)
{
- return(setpgid(pid, pgid));
+ return(setpgid(0, 0));
}
Index: regress/lib/libc/Makefile
===
RCS file: /OpenBSD/src/regress/lib/libc/Makefile,v
retrieving revision 1.43
diff -u -p -u -p -r1.43 Makefile
--- regress/lib/libc/Makefile 3 Jul 2014 21:12:24 - 1.43
+++ regress/lib/libc/Makefile 16 Sep 2014 21:27:35 -
@@ -5,7 +5,7 @@ SUBDIR+= atexit basename cephes cxa-atex
SUBDIR+= explicit_bzero fmemopen fnmatch fpclassify getcap getopt_long glob
SUBDIR+= hsearch longjmp locale malloc mkstemp modf netdb open_memstream
SUBDIR+= orientation popen printf
-SUBDIR+= regex setjmp setjmp-signal sigreturn sigsetjmp sprintf
+SUBDIR+= regex setjmp setjmp-signal setpgrp sigreturn sigsetjmp sprintf
SUBDIR+= stdio_threading stpncpy strerror strtod strtol strtonum
SUBDIR+= telldir time timingsafe vis
Index: sbin/iked/proc.c
===
RCS file: /OpenBSD/src/sbin/iked/proc.c,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 proc.c
--- sbin/iked/proc.c18 Aug 2014 09:43:02 - 1.19
+++ sbin/iked/proc.c16 Sep 2014 21:27:38 -
@@ -352,7 +352,7 @@ proc_run(struct privsep *ps, struct priv
fatal("proc_run: cannot fork");
case 0:
/* Set the process group of the current process */
- setpgrp(0, getpid());
+ setpgid(0, getpid());
Re: improve ressl config setting
On Fri, Sep 12, 2014 at 20:04, Ted Unangst wrote:
The neverending slog towards greatness continues.
Index: ressl.c
===
RCS file: /cvs/src/lib/libressl/ressl.c,v
retrieving revision 1.12
diff -u -p -r1.12 ressl.c
--- ressl.c 15 Aug 2014 16:55:32 - 1.12
+++ ressl.c 11 Sep 2014 19:18:49 -
@@ -29,7 +29,7 @@
#include
#include "ressl_internal.h"
-extern struct ressl_config ressl_config_default;
+static struct ressl_config *ressl_config_default;
int
ressl_init(void)
@@ -42,6 +42,9 @@ ressl_init(void)
SSL_load_error_strings();
SSL_library_init();
+ if ((ressl_config_default = ressl_config_new()) == NULL)
+ return (-1);
+
ressl_initialised = 1;
return (0);
@@ -78,7 +81,7 @@ ressl_new(void)
if ((ctx = calloc(1, sizeof(*ctx))) == NULL)
return (NULL);
- ctx->config = &ressl_config_default;
+ ctx->config = ressl_config_default;
ressl_reset(ctx);
@@ -89,7 +92,7 @@ int
ressl_configure(struct ressl *ctx, struct ressl_config *config)
{
if (config == NULL)
- config = &ressl_config_default;
+ config = ressl_config_default;
ctx->config = config;
Index: ressl.h
===
RCS file: /cvs/src/lib/libressl/ressl.h,v
retrieving revision 1.13
diff -u -p -r1.13 ressl.h
--- ressl.h 27 Aug 2014 10:46:53 - 1.13
+++ ressl.h 16 Sep 2014 18:07:10 -
@@ -31,15 +31,15 @@ const char *ressl_error(struct ressl *ct
struct ressl_config *ressl_config_new(void);
void ressl_config_free(struct ressl_config *config);
-void ressl_config_set_ca_file(struct ressl_config *config, char *ca_file);
-void ressl_config_set_ca_path(struct ressl_config *config, char *ca_path);
-void ressl_config_set_cert_file(struct ressl_config *config, char *cert_file);
-void ressl_config_set_cert_mem(struct ressl_config *config, char *cert,
+int ressl_config_set_ca_file(struct ressl_config *config, const char *ca_file);
+int ressl_config_set_ca_path(struct ressl_config *config, const char *ca_path);
+int ressl_config_set_cert_file(struct ressl_config *config, const char
*cert_file);
+int ressl_config_set_cert_mem(struct ressl_config *config, const uint8_t *cert,
size_t len);
-void ressl_config_set_ciphers(struct ressl_config *config, char *ciphers);
+int ressl_config_set_ciphers(struct ressl_config *config, const char *ciphers);
int ressl_config_set_ecdhcurve(struct ressl_config *config, const char *);
-void ressl_config_set_key_file(struct ressl_config *config, char *key_file);
-void ressl_config_set_key_mem(struct ressl_config *config, char *key,
+int ressl_config_set_key_file(struct ressl_config *config, const char
*key_file);
+int ressl_config_set_key_mem(struct ressl_config *config, const uint8_t *key,
size_t len);
void ressl_config_set_verify_depth(struct ressl_config *config,
int verify_depth);
Index: ressl_config.c
===
RCS file: /cvs/src/lib/libressl/ressl_config.c,v
retrieving revision 1.8
diff -u -p -r1.8 ressl_config.c
--- ressl_config.c 27 Aug 2014 10:46:53 - 1.8
+++ ressl_config.c 16 Sep 2014 18:09:27 -
@@ -21,27 +21,60 @@
#include
#include "ressl_internal.h"
-/*
- * Default configuration.
- */
-struct ressl_config ressl_config_default = {
- .ca_file = _PATH_SSL_CA_FILE,
- .ca_path = NULL,
- .ciphers = NULL,
- .ecdhcurve = NID_X9_62_prime256v1,
- .verify = 1,
- .verify_depth = 6,
-};
+static int
+set_string(const char **dest, const char *src)
+{
+ free((char *)*dest);
+ *dest = NULL;
+ if (src != NULL)
+ if ((*dest = strdup(src)) == NULL)
+ return -1;
+ return 0;
+}
+
+static void *
+memdup(const void *in, size_t len)
+{
+ void *out;
+
+ if ((out = malloc(len)) == NULL)
+ return NULL;
+ memcpy(out, in, len);
+ return out;
+}
+
+static int
+set_mem(char **dest, size_t *destlen, const void *src, size_t srclen)
+{
+ free(*dest);
+ *dest = NULL;
+ *destlen = 0;
+ if (src != NULL)
+ if ((*dest = memdup(src, srclen)) == NULL)
+ return -1;
+ *destlen = srclen;
+ return 0;
+}
struct ressl_config *
ressl_config_new(void)
{
struct ressl_config *config;
- if ((config = malloc(sizeof(*config))) == NULL)
+ if ((config = calloc(1, sizeof(*config))) == NULL)
return (NULL);
- memcpy(config, &ressl_config_default, sizeof(*config));
+ /*
+* Default configuration.
+*/
+ if (ressl_config_set_ca_file(config, _PATH_SSL_CA_FILE) != 0) {
+ ressl_config_free(config);
+ return (NULL);
+ }
+ ressl_config_verify(config);
+ ressl_
Re: update: sqlite-3.8.6
On Mon, Sep 15, 2014 at 09:17:27AM -0400, James Turner wrote: > Attached you will find a diff that updates SQLite to the latest 3.8.6. > Tested on amd64 with the fossil port. landry@ is going to see if he can > get it in a bulk but other testing is also helpful. Thanks. Went into an amd64 bulk build without fallout, thanks for the update! Landry
Re: make top combine cpu lines by default if you have a lot of cpus
On Tue, Sep 16, 2014 at 21:51, David Gwynne wrote: > if you have more than 8 cpus, combine the cpu lines by default. > > ok? very nice.
b64_pton(src, NULL, len) shouldn't accept invalid Base64 strings
The function
int
b64_pton(char const *src, u_char *target, size_t targsize);
in src/lib/libc/net/base64.c has a small bug with no consequences in
the rest of the tree.
By design, b64_pton() can be called with a NULL pointer as `target', in
which case it calculates the number of bytes encoded in the Base64
string `src'. However, in presence of padding, the function doesn't
fully check whether the string is a valid Base64 string: It only counts
the number of padding characters and checks whether they occur in the
correct positions.
For instance, `b64_pton("//==", NULL, 1);' returns 1, even though "//=="
isn't actually a valid Base64 string.
The call `b64_pton("//==", target, 1);' correctly rejects the string
and returns -1.
Similarly, `b64_pton("///=", NULL, 2);' shouldn't return 2, but -1.
To fix this, I suggest to move the calculation of `nextbyte' in
states 1 and 2 out of the conditional `if (target)' and to use
`nextbyte' as a flag whether padding is allowed or not -- the current
character is allowed to be a padding character if and only if
(nextbyte == 0 && (state == 2 || state == 3)).
A nice side effect is that
if (target && tarindex < targsize && target[tarindex] != 0)
at the end of the routine can be replaced by the much simpler
if (nextbyte)
It makes more sense to me to bail out right away rather than deferring
this check to the end of the fiddling with the padding characters.
Index: base64.c
===
RCS file: /cvs/src/lib/libc/net/base64.c,v
retrieving revision 1.7
diff -u -p -r1.7 base64.c
--- base64.c31 Dec 2013 02:32:56 - 1.7
+++ base64.c16 Sep 2014 12:51:34 -
@@ -197,6 +197,7 @@ b64_pton(src, target, targsize)
u_char nextbyte;
char *pos;
+ nextbyte = 0;
state = 0;
tarindex = 0;
@@ -204,8 +205,17 @@ b64_pton(src, target, targsize)
if (isspace(ch))/* Skip whitespace anywhere. */
continue;
- if (ch == Pad64)
+ if (ch == Pad64) {
+ if (nextbyte)
+ /*
+* We're in state 2 or 3 and the last character
+* slopped over the last byte boundary into the
+* padded byte.
+*/
+ return (-1);
+
break;
+ }
pos = strchr(Base64, ch);
if (pos == 0) /* A non-base64 character. */
@@ -221,11 +231,11 @@ b64_pton(src, target, targsize)
state = 1;
break;
case 1:
+ nextbyte = ((pos - Base64) & 0x0f) << 4;
if (target) {
if (tarindex >= targsize)
return (-1);
target[tarindex] |= (pos - Base64) >> 4;
- nextbyte = ((pos - Base64) & 0x0f) << 4;
if (tarindex + 1 < targsize)
target[tarindex+1] = nextbyte;
else if (nextbyte)
@@ -235,11 +245,11 @@ b64_pton(src, target, targsize)
state = 2;
break;
case 2:
+ nextbyte = ((pos - Base64) & 0x03) << 6;
if (target) {
if (tarindex >= targsize)
return (-1);
target[tarindex] |= (pos - Base64) >> 2;
- nextbyte = ((pos - Base64) & 0x03) << 6;
if (tarindex + 1 < targsize)
target[tarindex+1] = nextbyte;
else if (nextbyte)
@@ -249,6 +259,7 @@ b64_pton(src, target, targsize)
state = 3;
break;
case 3:
+ nextbyte = 0;
if (target) {
if (tarindex >= targsize)
return (-1);
@@ -292,16 +303,6 @@ b64_pton(src, target, targsize)
for (; ch != '\0'; ch = (unsigned char)*src++)
if (!isspace(ch))
return (-1);
-
- /*
-* Now make sure for cases 2 and 3 that the "extra"
-* bits that slopped past the last full byte were
-* zeros. If we don't check them, they become a
-* subliminal channel.
-*/
- if (target && tarindex < targsize &&
- target[tarindex] != 0)
-
Re: pax: Unable to access ./usr/share/sysmerge/xetcsum: No such file or directory
On Tue, Sep 16, 2014 at 02:08:41PM +0100, Stuart Henderson wrote: > Anyone know if "pax: Unable to access ./usr/share/sysmerge/xetcsum: No > such file or directory" (end of mkx) is important? No. You can ignore it. -- Matthieu Herrb
pax: Unable to access ./usr/share/sysmerge/xetcsum: No such file or directory
Anyone know if "pax: Unable to access ./usr/share/sysmerge/xetcsum: No such file or directory" (end of mkx) is important?
Re: make top combine cpu lines by default if you have a lot of cpus
On September 16, 2014 2:11:28 PM CEST, Mark Kettenis
wrote:
>> Date: Tue, 16 Sep 2014 21:51:00 +1000
>> From: David Gwynne
>>
>> if you have more than 8 cpus, combine the cpu lines by default.
Just curious, is there a command line argument to expand the list?
/Alexander
>>
>> ok?
>
>8 seems a reasonable number
>
>ok kettenis@
>
>> Index: machine.c
>> ===
>> RCS file: /cvs/src/usr.bin/top/machine.c,v
>> retrieving revision 1.78
>> diff -u -p -r1.78 machine.c
>> --- machine.c4 Jul 2014 05:58:31 - 1.78
>> +++ machine.c16 Sep 2014 11:46:41 -
>> @@ -141,14 +141,26 @@ intncpu;
>> unsigned intmaxslp;
>>
>> int
>> -machine_init(struct statics *statics)
>> +getncpu(void)
>> {
>> +int mib[] = { CTL_HW, HW_NCPU };
>> +int ncpu;
>> size_t size = sizeof(ncpu);
>> -int mib[2], pagesize, cpu;
>>
>> -mib[0] = CTL_HW;
>> -mib[1] = HW_NCPU;
>> -if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
>> +if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
>> +&ncpu, &size, NULL, 0) == -1)
>> +return (-1);
>> +
>> +return (ncpu);
>> +}
>> +
>> +int
>> +machine_init(struct statics *statics)
>> +{
>> +int pagesize, cpu;
>> +
>> +ncpu = getncpu();
>> +if (ncpu == -1)
>> return (-1);
>> cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
>> if (cpu_states == NULL)
>> Index: machine.h
>> ===
>> RCS file: /cvs/src/usr.bin/top/machine.h,v
>> retrieving revision 1.17
>> diff -u -p -r1.17 machine.h
>> --- machine.h5 Jun 2012 18:52:53 - 1.17
>> +++ machine.h16 Sep 2014 11:46:41 -
>> @@ -93,3 +93,5 @@ extern char*format_next_process(cadd
>> extern uid_tproc_owner(pid_t);
>>
>> extern struct kinfo_proc*getprocs(int, int, int *);
>> +
>> +int getncpu(void);
>> Index: top.c
>> ===
>> RCS file: /cvs/src/usr.bin/top/top.c,v
>> retrieving revision 1.81
>> diff -u -p -r1.81 top.c
>> --- top.c7 Apr 2014 15:49:22 - 1.81
>> +++ top.c16 Sep 2014 11:46:41 -
>> @@ -250,6 +250,13 @@ parseargs(int ac, char **av)
>> }
>> }
>>
>> +i = getncpu();
>> +if (i == -1)
>> +err(1, NULL);
>> +
>> +if (i > 8)
>> +combine_cpus = 1;
>> +
>> /* get count of top processes to display (if any) */
>> if (optind < ac) {
>> if ((topn = atoiwi(av[optind])) == Invalid) {
>>
>>
Re: make top combine cpu lines by default if you have a lot of cpus
On 2014/09/16 21:51, David Gwynne wrote:
> int
> -machine_init(struct statics *statics)
> +getncpu(void)
> {
> + int mib[] = { CTL_HW, HW_NCPU };
> + int ncpu;
would it be better to use a different name for the local variable here
rather than shadowing the global?
I didn't find anything in style(9) about it, but it confused me for 20
seconds when I was reading the diff.
Re: make top combine cpu lines by default if you have a lot of cpus
> Date: Tue, 16 Sep 2014 21:51:00 +1000
> From: David Gwynne
>
> if you have more than 8 cpus, combine the cpu lines by default.
>
> ok?
8 seems a reasonable number
ok kettenis@
> Index: machine.c
> ===
> RCS file: /cvs/src/usr.bin/top/machine.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 machine.c
> --- machine.c 4 Jul 2014 05:58:31 - 1.78
> +++ machine.c 16 Sep 2014 11:46:41 -
> @@ -141,14 +141,26 @@ int ncpu;
> unsigned int maxslp;
>
> int
> -machine_init(struct statics *statics)
> +getncpu(void)
> {
> + int mib[] = { CTL_HW, HW_NCPU };
> + int ncpu;
> size_t size = sizeof(ncpu);
> - int mib[2], pagesize, cpu;
>
> - mib[0] = CTL_HW;
> - mib[1] = HW_NCPU;
> - if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
> + if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
> + &ncpu, &size, NULL, 0) == -1)
> + return (-1);
> +
> + return (ncpu);
> +}
> +
> +int
> +machine_init(struct statics *statics)
> +{
> + int pagesize, cpu;
> +
> + ncpu = getncpu();
> + if (ncpu == -1)
> return (-1);
> cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
> if (cpu_states == NULL)
> Index: machine.h
> ===
> RCS file: /cvs/src/usr.bin/top/machine.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 machine.h
> --- machine.h 5 Jun 2012 18:52:53 - 1.17
> +++ machine.h 16 Sep 2014 11:46:41 -
> @@ -93,3 +93,5 @@ extern char*format_next_process(cadd
> extern uid_tproc_owner(pid_t);
>
> extern struct kinfo_proc *getprocs(int, int, int *);
> +
> +int getncpu(void);
> Index: top.c
> ===
> RCS file: /cvs/src/usr.bin/top/top.c,v
> retrieving revision 1.81
> diff -u -p -r1.81 top.c
> --- top.c 7 Apr 2014 15:49:22 - 1.81
> +++ top.c 16 Sep 2014 11:46:41 -
> @@ -250,6 +250,13 @@ parseargs(int ac, char **av)
> }
> }
>
> + i = getncpu();
> + if (i == -1)
> + err(1, NULL);
> +
> + if (i > 8)
> + combine_cpus = 1;
> +
> /* get count of top processes to display (if any) */
> if (optind < ac) {
> if ((topn = atoiwi(av[optind])) == Invalid) {
>
>
make top combine cpu lines by default if you have a lot of cpus
if you have more than 8 cpus, combine the cpu lines by default.
ok?
Index: machine.c
===
RCS file: /cvs/src/usr.bin/top/machine.c,v
retrieving revision 1.78
diff -u -p -r1.78 machine.c
--- machine.c 4 Jul 2014 05:58:31 - 1.78
+++ machine.c 16 Sep 2014 11:46:41 -
@@ -141,14 +141,26 @@ int ncpu;
unsigned int maxslp;
int
-machine_init(struct statics *statics)
+getncpu(void)
{
+ int mib[] = { CTL_HW, HW_NCPU };
+ int ncpu;
size_t size = sizeof(ncpu);
- int mib[2], pagesize, cpu;
- mib[0] = CTL_HW;
- mib[1] = HW_NCPU;
- if (sysctl(mib, 2, &ncpu, &size, NULL, 0) == -1)
+ if (sysctl(mib, sizeof(mib) / sizeof(mib[0]),
+ &ncpu, &size, NULL, 0) == -1)
+ return (-1);
+
+ return (ncpu);
+}
+
+int
+machine_init(struct statics *statics)
+{
+ int pagesize, cpu;
+
+ ncpu = getncpu();
+ if (ncpu == -1)
return (-1);
cpu_states = calloc(ncpu, CPUSTATES * sizeof(int64_t));
if (cpu_states == NULL)
Index: machine.h
===
RCS file: /cvs/src/usr.bin/top/machine.h,v
retrieving revision 1.17
diff -u -p -r1.17 machine.h
--- machine.h 5 Jun 2012 18:52:53 - 1.17
+++ machine.h 16 Sep 2014 11:46:41 -
@@ -93,3 +93,5 @@ extern char*format_next_process(cadd
extern uid_tproc_owner(pid_t);
extern struct kinfo_proc *getprocs(int, int, int *);
+
+intgetncpu(void);
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving revision 1.81
diff -u -p -r1.81 top.c
--- top.c 7 Apr 2014 15:49:22 - 1.81
+++ top.c 16 Sep 2014 11:46:41 -
@@ -250,6 +250,13 @@ parseargs(int ac, char **av)
}
}
+ i = getncpu();
+ if (i == -1)
+ err(1, NULL);
+
+ if (i > 8)
+ combine_cpus = 1;
+
/* get count of top processes to display (if any) */
if (optind < ac) {
if ((topn = atoiwi(av[optind])) == Invalid) {
Re: patch: acpitz: active cooling and notify 0x81
On Mon, Sep 15, 2014 at 04:57:24PM +0200, S??bastien Marie wrote:
> ping ?
>
> Tihs patch is very conservative: it just allow to switch fan OFF if
> state is unknown.
I finally read through the relevant parts of the spec. The problem
here is that it looks like we are implementing thermal zone hysteresis
incorrectly. I think you noticed this in your original diff, but IMO
we've gone down a bit of a wrong path here with these later diffs.
I'll take a look at the hysteresis code tomorrow and see if I can come
up with something better.
Thanks.
-ml
PS the relevant part of the spec is 11.1.2.3 "Resetting Cooling Temperatures
to implement Hysteresis"
>
> Thanks.
> --
> S??bastien Marie
>
> On Wed, Aug 27, 2014 at 02:51:20PM +0200, S??bastien Marie wrote:
> > Hi Jonathan,
> >
> > First, thanks for your feedback and for your patch.
> >
> > On Wed, Aug 27, 2014 at 02:42:43AM +1000, Jonathan Gray wrote:
> > > Rather than calling acpi_setfan() again would it make
> > > sense to remove the cached state value and move
> > > the state reading to just before the method is called?
> > >
> > > That said I'm not familiar with the acpitz code and
> > > haven't gone off to look at the spec.
> >
> > At first reading I am quite disappointed to remove caching.
> >
> > So I have:
> > - checked in others acpi termal-zone implementation to see if caching
> >is using or not for active cooling.
> > - try to measure some values on my host.
> >
> >
> > Others implementations checked:
> > - netbsd : caching used (sys/dev/acpi/acpi_tz.c, l.368)
> > - freebsd : caching used (head/sys/dev/acpica/acpi_thermal.c, l.564)
> > - linux : caching seems not be used (but not 100% sure)
> >
> > (please note I am not expert in theses kernels implementations, so I
> > could be wrong).
> >
> >
> > Some measures:
> >
> > I first try to measure the cost of acpi_setfan in term of time:
> > something between 9998432ns et 14574920ns (0.0099 and 0.015 s). It
> > seems not being a heavy operation (too my eyes).
> >
> >
> > Secondly, the number of call of acpi_setfan, with and without caching.
> >
> > The test kernel is build with caching enable. The without-caching
> > counter is incremented every time acpi_setfan would be call without
> > caching, and with-caching counter incremented only when acpi_setfan is
> > called (the patch below was applied: an unknown state would result
> > acpi_setfan calling).
> >
> > During 1h09 :
> > - without caching: 3388 calls
> > - with caching: 742 calls
> >
> > The cache is used at 78% of time.
> >
> >
> > So, even if your patch resolve the initial problem (the fan don't keep
> > running whereas state is unknown), I would prefer to keep the cache in
> > place. But if you think the impact of not use this cache is negligible,
> > it is ok for me.
> >
> > I join a very conservative patch which just allow calling
> > acpi_setfan(sc,i,"_OFF") if cache is unknown.
> >
> > Thanks.
> > --
> > S??bastien Marie
> >
> >
> > Index: dev/acpi/acpitz.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpitz.c,v
> > retrieving revision 1.47
> > diff -u -p -r1.47 acpitz.c
> > --- dev/acpi/acpitz.c 12 Jul 2014 02:44:49 - 1.47
> > +++ dev/acpi/acpitz.c 27 Aug 2014 12:38:36 -
> > @@ -424,7 +424,7 @@ acpitz_refresh(void *arg)
> > acpitz_setfan(sc, i, "_ON_");
> > } else if (sc->sc_ac[i] != -1) {
> > /* turn off fan i */
> > - if (sc->sc_ac_stat[i] > 0)
> > + if (sc->sc_ac_stat[i] == -1 || sc->sc_ac_stat[i] > 0)
> > acpitz_setfan(sc, i, "_OFF");
> > }
> > }
>
Re: Speeding up openbsd on amd64 MP
On Sun, Sep 14, 2014 at 10:54 PM, Stefan Fritsch wrote: > I would like people to test the diffs on other machines. In particular on > non-Intel CPUs. The only AMD system I could get hold of did not run > reliably with openbsd even without the pmap diff. r815 MP forktest1.54 r815 MP kernel -j41.02 r815 MP kernel -j301.07 dell r815 with 4 x amd opteron 6128 (32 cores), 128gb ram.
