Alert - The Branding Revolution
As you know the world's biggest branding revolution starts January 2012. What direct implications does it have for your organization? What do your teams need to know now and what must they be prepared for in advance to face the tidal wave? This White Paper provides an in-depth overview and can be downloaded directly download from the AARM web site at http://www.aarm.org I hope you'll find it helpful. Robert Robert T. Stacey President - AARM roberttsta...@aarm.org akt ___ If you have received this email in errror please accept my apologies. Insert removal in the subject line and email to remo...@aarm.org and I'll see that appropriate action is taken. To reach the AARM website AARM WEB
diff: str[n]cmp in ksh(1)
Hi tech,
I have a simple diff for ksh(1) which takes
care to not read past the end of the static
buffer 'holdbuf' where the length of 'pat'
is greater than the buffer.
Does anyone think this is worthwhile? If not,
should we remove the XXX comment altogether?
- Michael
Index: vi.c
===
RCS file: /usr/src/cvs/src/bin/ksh/vi.c,v
retrieving revision 1.26
diff -u -r1.26 vi.c
--- vi.c29 Jun 2009 22:50:19 - 1.26
+++ vi.c17 Nov 2011 13:35:25 -
@@ -1675,8 +1675,8 @@
anchored = *pat == '^' ? (++pat, 1) : 0;
if ((hist = findhist(start, fwd, pat, anchored)) 0) {
/* if (start != 0 fwd match(holdbuf, pat) = 0) { */
- /* XXX should strcmp be strncmp? */
- if (start != 0 fwd strcmp(holdbuf, pat) = 0) {
+ if (start != 0 fwd
+ strncmp(holdbuf, pat, sizeof(holdbuf)) = 0) {
restore_cbuf();
return 0;
} else
Allow clang++ to work on OpenBSD
Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h26 May 2010 11:23:06 - 1.2 +++ os_defines.h17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; #endif
Re: alpha and gcc4; have foot, will shoot
Janjaap van Velthooven janj...@stack.nl wrote: For some obscure reason this gave successes. After splitting up alpha/rtld_machine.c into 2 or mor parts, any combination where the 1st and the 3rd function (_dl_md_reloc and _dl_md_reloc_got) were not in the same source allowed the split-up sources to be compiled without breaking ld.so. Looking with my untrained eye at the generated assembly or the dissasembled objects did not give me any clue as to why this was happening. I split _dl_md_reloc_got() out into a separate file and compared the generated assembly language. There are no differences. I also disassembled the object files, no code differences. I wonder if ld(1) could be to blame. -- Christian naddy Weisgerber na...@mips.inka.de
Re: alpha and gcc4; have foot, will shoot
Christian Weisgerber wrote and mailed: Janjaap van Velthooven janj...@stack.nl wrote: For some obscure reason this gave successes. After splitting up alpha/rtld_machine.c into 2 or mor parts, any combination where the 1st and the 3rd function (_dl_md_reloc and _dl_md_reloc_got) were not in the same source allowed the split-up sources to be compiled without breaking ld.so. Looking with my untrained eye at the generated assembly or the dissasembled objects did not give me any clue as to why this was happening. I split _dl_md_reloc_got() out into a separate file and compared the generated assembly language. There are no differences. I also disassembled the object files, no code differences. I did similar and saw no noticable differences either, other than the address the function was on that is.. I wonder if ld(1) could be to blame. If so, why would it do that? It should behave the same as when compiled with gcc3 (theoretically at least).. I can think of some theories: - does compiling ld with gcc4 introduce/expose a bug in ld? (I used a gcc4 compiled ld back then) - does the gcc4 compiled rtld_machine.c cause an other codepath than the gcc3 compiled version in ld on which there has always been a bug? Janjaap van Velthooven -- / __/ /_/ __/ /_ __/ __/ /___ / / /_ __/___/_/_ /___ / / __/ /___ / / janj...@stack.nl /___/_/_/_/_/_/_/___/_/_/
Re: libedit wchar allocation issue
Sure, looks good, I'll use your version.
On Wed, Nov 16, 2011 at 02:00:51PM +0100, Stefan Sperling wrote:
On Tue, Nov 15, 2011 at 11:09:08PM +, Nicholas Marriott wrote:
Hi
libedit miscalculates the amount of space needed for constructing it's
wchar_t version of argv, causing it to overrun the buffer.
I don't see how the output of mbstowcs can be longer than
(sum(strlen(argv)) * sizeof (wchar_t)) so this fix should work:
ok?
Index: chartype.c
===
RCS file: /cvs/src/lib/libedit/chartype.c,v
retrieving revision 1.3
diff -u -p -r1.3 chartype.c
--- chartype.c 7 Jul 2011 05:40:42 - 1.3
+++ chartype.c 15 Nov 2011 00:38:44 -
@@ -147,7 +147,7 @@ ct_decode_argv(int argc, const char *arg
* the argv strings. */
for (i = 0, bufspace = 0; i argc; ++i)
bufspace += argv[i] ? strlen(argv[i]) + 1 : 0;
- ct_conv_buff_resize(conv, 0, bufspace);
+ ct_conv_buff_resize(conv, 0, bufspace * sizeof(*p));
if (!conv-wsize)
return NULL;
OK, your fix is good (with or without my suggestion below).
Even though we have enough space the code should properly evaluate
what mbstowcs() returns, if only to provide a good example.
Renaming the variable isn't strictly needed but 'bytes' is very misleading.
Index: chartype.c
===
RCS file: /cvs/src/lib/libedit/chartype.c,v
retrieving revision 1.3
diff -u -p -r1.3 chartype.c
--- chartype.c7 Jul 2011 05:40:42 - 1.3
+++ chartype.c16 Nov 2011 12:40:13 -
@@ -141,13 +141,13 @@ ct_decode_argv(int argc, const char *arg
int i;
Char *p;
Char **wargv;
- ssize_t bytes;
+ size_t wlen;
/* Make sure we have enough space in the conversion buffer to store all
* the argv strings. */
for (i = 0, bufspace = 0; i argc; ++i)
bufspace += argv[i] ? strlen(argv[i]) + 1 : 0;
- ct_conv_buff_resize(conv, 0, bufspace);
+ ct_conv_buff_resize(conv, 0, bufspace * sizeof(*p));
if (!conv-wsize)
return NULL;
@@ -159,15 +159,16 @@ ct_decode_argv(int argc, const char *arg
continue;
} else {
wargv[i] = p;
- bytes = mbstowcs(p, argv[i], bufspace);
+ wlen = mbstowcs(p, argv[i], bufspace);
}
- if (bytes == -1) {
+ if (wlen == (size_t)-1 || wlen == bufspace) {
+ /* Encoding error or not enough room for NUL. */
el_free(wargv);
return NULL;
} else
- bytes++; /* include '\0' in the count */
- bufspace -= bytes;
- p += bytes;
+ wlen++; /* include NUL in the count */
+ bufspace -= wlen;
+ p += wlen;
}
return wargv;
Re: diff: str[n]cmp in ksh(1)
On Thu, Nov 17, 2011 at 09:48:36PM +0800, Michael W. Bombardieri wrote:
Hi tech,
I have a simple diff for ksh(1) which takes
care to not read past the end of the static
buffer 'holdbuf' where the length of 'pat'
is greater than the buffer.
holdbuf is zero-terminated, so strcmp() won't go past the end of
holdbuf, and seems more appropriate
Does anyone think this is worthwhile? If not,
should we remove the XXX comment altogether?
- Michael
Index: vi.c
===
RCS file: /usr/src/cvs/src/bin/ksh/vi.c,v
retrieving revision 1.26
diff -u -r1.26 vi.c
--- vi.c 29 Jun 2009 22:50:19 - 1.26
+++ vi.c 17 Nov 2011 13:35:25 -
@@ -1675,8 +1675,8 @@
anchored = *pat == '^' ? (++pat, 1) : 0;
if ((hist = findhist(start, fwd, pat, anchored)) 0) {
/* if (start != 0 fwd match(holdbuf, pat) = 0) { */
- /* XXX should strcmp be strncmp? */
- if (start != 0 fwd strcmp(holdbuf, pat) = 0) {
+ if (start != 0 fwd
+ strncmp(holdbuf, pat, sizeof(holdbuf)) = 0) {
restore_cbuf();
return 0;
} else
-- Alexandre
Expose some scheduler statistics to userland via sysctl
Moving this to tech@
Hi,
I was studying the scheduler code after watching tedu's talk, I'd like
to expose this statistics to userland so that I can try playing with
cache affinity in the future:
gimli:src: sysctl kern.schedstat
kern.schedstat.nmigrations=23744
kern.schedstat.noidle=0
kern.schedstat.stolen=9170
kern.schedstat.choose=834843
kern.schedstat.wasidle=808711
kern.schedstat.nomigrations=2388
Opinions ?
Index: sys/sys//sched.h
===
RCS file: /cvs/src/sys/sys/sched.h,v
retrieving revision 1.29
diff -d -u -p -w -r1.29 sched.h
--- sys/sys//sched.h7 Jul 2011 18:00:33 - 1.29
+++ sys/sys//sched.h12 Nov 2011 13:51:04 -
@@ -75,6 +75,34 @@
* Posix defines a sched.h which may want to include sys/sched.h
*/
+struct schedstat {
+ u_int64_t scs_nmigrations;
+ u_int64_t scs_noidle;
+ u_int64_t scs_stolen;
+
+ u_int64_t scs_choose;
+ u_int64_t scs_wasidle;
+ u_int64_t scs_nomigrations;
+};
+
+/* These sysctl names are only really used by sysctl(8) */
+#define KERN_SCHEDSTAT_NMIGRATIONS 1
+#define KERN_SCHEDSTAT_NOIDLE 2
+#define KERN_SCHEDSTAT_STOLEN 3
+#define KERN_SCHEDSTAT_CHOOSE 4
+#define KERN_SCHEDSTAT_WASIDLE 5
+#define KERN_SCHEDSTAT_NOMIGRATIONS6
+#define KERN_SCHEDSTAT_MAXID 7
+
+#define CTL_KERN_SCHEDSTAT_NAMES { \
+ { 0, 0 }, \
+ { nmigrations, CTLTYPE_QUAD },\
+ { noidle, CTLTYPE_QUAD }, \
+ { stolen, CTLTYPE_QUAD }, \
+ { choose, CTLTYPE_QUAD }, \
+ { wasidle, CTLTYPE_QUAD },\
+ { nomigrations, CTLTYPE_QUAD }\
+}
/*
* CPU states.
* XXX Not really scheduler state, but no other good place to put
Index: sys/sys//sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.117
diff -d -u -p -w -r1.117 sysctl.h
--- sys/sys//sysctl.h 30 Aug 2011 01:09:29 - 1.117
+++ sys/sys//sysctl.h 12 Nov 2011 13:40:45 -
@@ -189,7 +189,8 @@ struct ctlname {
#defineKERN_CONSDEV75 /* dev_t: console terminal
device */
#defineKERN_NETLIVELOCKS 76 /* int: number of network
livelocks */
#defineKERN_POOL_DEBUG 77 /* int: enable pool_debug */
-#defineKERN_MAXID 78 /* number of valid kern ids */
+#define KERN_SCHEDSTAT 78 /* struct: sched statistics */
+#defineKERN_MAXID 79 /* number of valid kern ids */
#defineCTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -270,6 +271,7 @@ struct ctlname {
{ consdev, CTLTYPE_STRUCT }, \
{ netlivelocks, CTLTYPE_INT }, \
{ pool_debug, CTLTYPE_INT }, \
+ { schedstat, CTLTYPE_STRUCT }, \
}
/*
Index: sys/kern//kern_sched.c
===
RCS file: /cvs/src/sys/kern/kern_sched.c,v
retrieving revision 1.24
diff -d -u -p -w -r1.24 kern_sched.c
--- sys/kern//kern_sched.c 12 Oct 2011 18:30:09 - 1.24
+++ sys/kern//kern_sched.c 12 Nov 2011 14:41:59 -
@@ -35,6 +35,8 @@ void sched_kthreads_create(void *);
int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
struct proc *sched_steal_proc(struct cpu_info *);
+struct schedstat schedstat;
+
/*
* To help choosing which cpu should run which process we keep track
* of cpus which are currently idle and which cpus have processes
@@ -301,14 +303,6 @@ again:
return (p);
}
-uint64_t sched_nmigrations;
-uint64_t sched_noidle;
-uint64_t sched_stolen;
-
-uint64_t sched_choose;
-uint64_t sched_wasidle;
-uint64_t sched_nomigrations;
-
struct cpu_info *
sched_choosecpu_fork(struct proc *parent, int flags)
{
@@ -374,7 +368,7 @@ sched_choosecpu(struct proc *p)
if (p-p_flag P_CPUPEG)
return (p-p_cpu);
- sched_choose++;
+ schedstat.scs_choose++;
/*
* Look at all cpus that are currently idle and have nothing queued.
@@ -393,7 +387,7 @@ sched_choosecpu(struct proc *p)
if (cpuset_isset(set, p-p_cpu) ||
(p-p_cpu == curcpu() p-p_cpu-ci_schedstate.spc_nrun == 0
curproc == p)) {
- sched_wasidle++;
+ schedstat.scs_wasidle++;
return (p-p_cpu);
}
@@ -411,9 +405,9 @@ sched_choosecpu(struct proc *p)
}
if (p-p_cpu != choice)
- sched_nmigrations++;
+ schedstat.scs_nmigrations++;
else
- sched_nomigrations++;
+ schedstat.scs_nomigrations++;
return (choice);
}
@@ -461,7 +455,7 @@ sched_steal_proc(struct cpu_info *self)
Re: Expose some scheduler statistics to userland via sysctl
On 2011 Nov 17 (Thu) at 21:18:24 -0200 (-0200), Christiano F. Haesbaert wrote:
Moving this to tech@
Hi,
I was studying the scheduler code after watching tedu's talk, I'd like
to expose this statistics to userland so that I can try playing with
cache affinity in the future:
gimli:src: sysctl kern.schedstat
kern.schedstat.nmigrations=23744
kern.schedstat.noidle=0
kern.schedstat.stolen=9170
kern.schedstat.choose=834843
kern.schedstat.wasidle=808711
kern.schedstat.nomigrations=2388
Opinions ?
I see no point in exporting this out. They are essentially pointless
knobs that people _will_ fiddle with without a clue.
This belongs in a developers tree IMO.
Index: sys/sys//sched.h
===
RCS file: /cvs/src/sys/sys/sched.h,v
retrieving revision 1.29
diff -d -u -p -w -r1.29 sched.h
--- sys/sys//sched.h 7 Jul 2011 18:00:33 - 1.29
+++ sys/sys//sched.h 12 Nov 2011 13:51:04 -
@@ -75,6 +75,34 @@
* Posix defines a sched.h which may want to include sys/sched.h
*/
+struct schedstat {
+ u_int64_t scs_nmigrations;
+ u_int64_t scs_noidle;
+ u_int64_t scs_stolen;
+
+ u_int64_t scs_choose;
+ u_int64_t scs_wasidle;
+ u_int64_t scs_nomigrations;
+};
+
+/* These sysctl names are only really used by sysctl(8) */
+#define KERN_SCHEDSTAT_NMIGRATIONS 1
+#define KERN_SCHEDSTAT_NOIDLE2
+#define KERN_SCHEDSTAT_STOLEN3
+#define KERN_SCHEDSTAT_CHOOSE4
+#define KERN_SCHEDSTAT_WASIDLE 5
+#define KERN_SCHEDSTAT_NOMIGRATIONS 6
+#define KERN_SCHEDSTAT_MAXID 7
+
+#define CTL_KERN_SCHEDSTAT_NAMES { \
+ { 0, 0 }, \
+ { nmigrations, CTLTYPE_QUAD },\
+ { noidle, CTLTYPE_QUAD }, \
+ { stolen, CTLTYPE_QUAD }, \
+ { choose, CTLTYPE_QUAD }, \
+ { wasidle, CTLTYPE_QUAD },\
+ { nomigrations, CTLTYPE_QUAD }\
+}
/*
* CPU states.
* XXX Not really scheduler state, but no other good place to put
Index: sys/sys//sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.117
diff -d -u -p -w -r1.117 sysctl.h
--- sys/sys//sysctl.h 30 Aug 2011 01:09:29 - 1.117
+++ sys/sys//sysctl.h 12 Nov 2011 13:40:45 -
@@ -189,7 +189,8 @@ struct ctlname {
#define KERN_CONSDEV75 /* dev_t: console terminal
device */
#define KERN_NETLIVELOCKS 76 /* int: number of network
livelocks */
#define KERN_POOL_DEBUG 77 /* int: enable pool_debug */
-#define KERN_MAXID 78 /* number of valid kern ids */
+#define KERN_SCHEDSTAT 78 /* struct: sched statistics */
+#define KERN_MAXID 79 /* number of valid kern ids */
#define CTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -270,6 +271,7 @@ struct ctlname {
{ consdev, CTLTYPE_STRUCT }, \
{ netlivelocks, CTLTYPE_INT }, \
{ pool_debug, CTLTYPE_INT }, \
+ { schedstat, CTLTYPE_STRUCT }, \
}
/*
Index: sys/kern//kern_sched.c
===
RCS file: /cvs/src/sys/kern/kern_sched.c,v
retrieving revision 1.24
diff -d -u -p -w -r1.24 kern_sched.c
--- sys/kern//kern_sched.c12 Oct 2011 18:30:09 - 1.24
+++ sys/kern//kern_sched.c12 Nov 2011 14:41:59 -
@@ -35,6 +35,8 @@ void sched_kthreads_create(void *);
int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
struct proc *sched_steal_proc(struct cpu_info *);
+struct schedstat schedstat;
+
/*
* To help choosing which cpu should run which process we keep track
* of cpus which are currently idle and which cpus have processes
@@ -301,14 +303,6 @@ again:
return (p);
}
-uint64_t sched_nmigrations;
-uint64_t sched_noidle;
-uint64_t sched_stolen;
-
-uint64_t sched_choose;
-uint64_t sched_wasidle;
-uint64_t sched_nomigrations;
-
struct cpu_info *
sched_choosecpu_fork(struct proc *parent, int flags)
{
@@ -374,7 +368,7 @@ sched_choosecpu(struct proc *p)
if (p-p_flag P_CPUPEG)
return (p-p_cpu);
- sched_choose++;
+ schedstat.scs_choose++;
/*
* Look at all cpus that are currently idle and have nothing queued.
@@ -393,7 +387,7 @@ sched_choosecpu(struct proc *p)
if (cpuset_isset(set, p-p_cpu) ||
(p-p_cpu == curcpu() p-p_cpu-ci_schedstate.spc_nrun == 0
curproc == p)) {
- sched_wasidle++;
+ schedstat.scs_wasidle++;
return (p-p_cpu);
}
@@ -411,9 +405,9 @@ sched_choosecpu(struct proc
Re: Expose some scheduler statistics to userland via sysctl
On Fri, Nov 18, 2011, Thordur Bjornsson wrote: On 2011 Nov 17 (Thu) at 21:18:24 -0200 (-0200), Christiano F. Haesbaert wrote: Moving this to tech@ Hi, I was studying the scheduler code after watching tedu's talk, I'd like to expose this statistics to userland so that I can try playing with cache affinity in the future: gimli:src: sysctl kern.schedstat kern.schedstat.nmigrations=23744 kern.schedstat.noidle=0 kern.schedstat.stolen=9170 kern.schedstat.choose=834843 kern.schedstat.wasidle=808711 kern.schedstat.nomigrations=2388 Opinions ? I see no point in exporting this out. They are essentially pointless knobs that people _will_ fiddle with without a clue. ??? They're readonly.
Re: Expose some scheduler statistics to userland via sysctl
On 17 November 2011 23:39, Ted Unangst t...@tedunangst.com wrote: On Fri, Nov 18, 2011, Thordur Bjornsson wrote: On 2011 Nov 17 (Thu) at 21:18:24 -0200 (-0200), Christiano F. Haesbaert wrote: Moving this to tech@ Hi, I was studying the scheduler code after watching tedu's talk, I'd like to expose this statistics to userland so that I can try playing with cache affinity in the future: gimli:src: sysctl kern.schedstat kern.schedstat.nmigrations=23744 kern.schedstat.noidle=0 kern.schedstat.stolen=9170 kern.schedstat.choose=834843 kern.schedstat.wasidle=808711 kern.schedstat.nomigrations=2388 Opinions ? I see no point in exporting this out. They are essentially pointless knobs that people _will_ fiddle with without a clue. ??? They're readonly. Mike just pointed out I can get those with pstat, so that solves my problem. Still maybe there is a place for sysctl, but I'm not too strong about it anymore. What is the line between sysctl vs globals ?
Re: Expose some scheduler statistics to userland via sysctl
On 18 November 2011 00:59, Christiano F. Haesbaert haesba...@haesbaert.org wrote: On 17 November 2011 23:39, Ted Unangst t...@tedunangst.com wrote: On Fri, Nov 18, 2011, Thordur Bjornsson wrote: On 2011 Nov 17 (Thu) at 21:18:24 -0200 (-0200), Christiano F. Haesbaert wrote: Moving this to tech@ Hi, I was studying the scheduler code after watching tedu's talk, I'd like to expose this statistics to userland so that I can try playing with cache affinity in the future: gimli:src: sysctl kern.schedstat kern.schedstat.nmigrations=23744 kern.schedstat.noidle=0 kern.schedstat.stolen=9170 kern.schedstat.choose=834843 kern.schedstat.wasidle=808711 kern.schedstat.nomigrations=2388 Opinions ? I see no point in exporting this out. They are essentially pointless knobs that people _will_ fiddle with without a clue. ??? They're readonly. Mike just pointed out I can get those with pstat, so that solves my problem. Still maybe there is a place for sysctl, but I'm not too strong about it anymore. What is the line between sysctl vs globals ? Checking again, it makes sense having the sysctl IMHO. We have something very similar in kern.forkstat, kern.nchstats, and the protocol stats.
Re: Expose some scheduler statistics to userland via sysctl
On Fri, Nov 18, 2011, Christiano F. Haesbaert wrote: What is the line between sysctl vs globals ? Checking again, it makes sense having the sysctl IMHO. We have something very similar in kern.forkstat, kern.nchstats, and the protocol stats. I think those stats are useful for a sysadmin to monitor performance, and there actions one can take to affect them. The scheduler is not really controllable. If you just want to peek at some values for debugging, pstat is the way to go. That's why I added it. ;)
