You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Jeremy F. <je...@go...> - 2004-01-08 22:42:29
|
On Thu, 2004-01-08 at 13:31, Dirk Mueller wrote: > On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > > > i386-linux machine-specific linux stuff > > i386-freebsd machine-specific freebsd stuff > > common-linux general linux stuff > > common-freebsd general freebsd stuff > > yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure > how "stable" uname -i is going to be (or if the next release of gentoo > hyperpatched will return i586 somewhen), and it didn't really save any code > as far as I can see. Well, i386 seems to be well accepted as the formal name for the architecture. I was a bit concerned that x86 might be ambigious with respect to x86-64 (if that's the proper architecture name). uname -i is supposed to return a generic CPU identifier; uname -m returns something more model-specific (i686). J |
|
From: Doug R. <df...@nl...> - 2004-01-08 22:09:18
|
On Thu, 2004-01-08 at 21:31, Dirk Mueller wrote: > On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > > > i386-linux machine-specific linux stuff > > i386-freebsd machine-specific freebsd stuff > > common-linux general linux stuff > > common-freebsd general freebsd stuff > > yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure > how "stable" uname -i is going to be (or if the next release of gentoo > hyperpatched will return i586 somewhen), and it didn't really save any code > as far as I can see. If you are intending to name the instruction set rather than some specific implementation of it, I think intel likes it to be called 'ia32' these days. Having said that, 'i386' is used almost universally as a name for this architecture. |
|
From: Dirk M. <dm...@gm...> - 2004-01-08 21:31:36
|
On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure how "stable" uname -i is going to be (or if the next release of gentoo hyperpatched will return i586 somewhen), and it didn't really save any code as far as I can see. > if it doesn't work out, I'm happy to throw it away. But I'd like to get > something like this in place as I merge the FreeBSD port (or before, and > merge FreeBSD into it). Yeah, thats what I started to do here locally already. > BTW: I put some stuff in the Makefile.am files which doesn't look good, > and surely can't be right - there seems to be a lot of duplication. How > can I fix this? Maybe something to do with aclocal? I think it should be handled with AC_SUBSTs, seems the cleanest solution to me. regarding Nicholas' question: I think putting all those nasty things in an arch/ subdir is the best solution, since we're going to have many subdirs and the extra subdir allows a very neat linking-together of the xxx-common and the common-xxx convenience libs into something that is then used for the coregrind targets. Dirk |
|
From: Nicholas N. <nj...@ca...> - 2004-01-08 21:20:24
|
On Thu, 8 Jan 2004, Jeremy Fitzhardinge wrote: > No, but if it isn't, then just don't look for the file. There's no > point in getting too heroic over it. Yeah, I'll do that. > It might also be useful to look in "." as well, since you might want a > program-specific config file. Or perhaps have an env var for looking > for multiple config files? Is this getting all too complex? I'm currently looking in three places: 1. ~/.valgrindrc 2. VALGRIND_OPTS 3. ./.valgrindrc Args are added in that order, the idea being that more 'local' args are added later, to override less local ones. (1) and (2) could be swapped, but (3) should definitely be last, as it's clearly the most local. N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-08 21:18:07
|
On Thu, 8 Jan 2004, Jeremy Fitzhardinge wrote: > To this end, I think we'll need a number of arch directories: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff > i386-common OS-independent i386 stuff > common-unix things common to Unix-like systems > > (I decided to go with CPU names like autoconf/uname -i uses) Sounds ok to me. One comment: do we need the arch/ directory? I prefer flat, wide directory structures to narrow, deep ones. Eg. we don't have a tools/ directory containing all the tool-specific directories. N |
|
From: Jeremy F. <je...@go...> - 2004-01-08 21:06:46
|
I've been thinking about how to rearrange the source tree to handle multiple OS and CPU combinations. I'm basing my thinking from looking at Doug's FreeBSD port, and Dirk's initial cut at an arch/ directory. It looks to me that there's a lot more in common between FreeBSD and Linux than I would have hoped for; almost all of vg_syscalls and vg_signals is intact, and vg_libpthread is mostly just syntactic changes rather than anything of substance. It would be really nice to put all that common stuff into a common place, to try and cut down on duplication. I'd also like to minimise #ifdefs in shared code. To this end, I think we'll need a number of arch directories: i386-linux machine-specific linux stuff i386-freebsd machine-specific freebsd stuff common-linux general linux stuff common-freebsd general freebsd stuff i386-common OS-independent i386 stuff common-unix things common to Unix-like systems (I decided to go with CPU names like autoconf/uname -i uses) So far, i386-linux/freebsd has things like vg_syscall.S, and the various very machine-dependent parts of ume. Later it will get things like the details of how to get/set syscall args for vg_syscalls.c, signal restart, etc. Also syscall numbering, and CPU-specific syscalls (LDT stuff, etc). common-linux/freebsd will probably get most of the rest of vg_signals where they differ, and probably most of the OS-specific parts of vg_syscalls.c i386-common will ultimately get most of vg_to/from_ucode.c. common-unix will get all the really generic syscall handling (things like read/write/exit/fork/exec, etc). I'm attaching my patch-in-progress. This is all still an experiment, so if it doesn't work out, I'm happy to throw it away. But I'd like to get something like this in place as I merge the FreeBSD port (or before, and merge FreeBSD into it). Comments? Thoughts? BTW: I put some stuff in the Makefile.am files which doesn't look good, and surely can't be right - there seems to be a lot of duplication. How can I fix this? Maybe something to do with aclocal? J |
|
From: Jeremy F. <je...@go...> - 2004-01-08 21:04:40
|
On Thu, 2004-01-08 at 10:44, Nicholas Nethercote wrote:
> How can I find the home directory -- is getenv("HOME") the right way?
> (Is $HOME always defined?)
No, but if it isn't, then just don't look for the file. There's no
point in getting too heroic over it.
It might also be useful to look in "." as well, since you might want a
program-specific config file. Or perhaps have an env var for looking
for multiple config files? Is this getting all too complex?
J
|
|
From: Robert W. <rj...@du...> - 2004-01-08 18:52:03
|
> I'm working on this, and I want to read ~/.valgrindrc. However, I can't
> use '~' in C because it's a shell thing, I think.
>
> How can I find the home directory -- is getenv("HOME") the right way?
> (Is $HOME always defined?)
It's not guaranteed to be, but it nearly always is. Another way is to
use getpwuid(getuid()) and pull out the pw_dir field from the result.
That should always work, unless the UID isn't in your password
database. Happily, with full virtualisation, this should now be usable
(getpwuid() is in libc, and actually more complicated than you might
imagine since it has to handle NIS, /etc/passwd, LDAP, etc.)
Regards,
Robert.
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-08 18:44:06
|
Hi,
I'm working on this, and I want to read ~/.valgrindrc. However, I can't
use '~' in C because it's a shell thing, I think.
How can I find the home directory -- is getenv("HOME") the right way?
(Is $HOME always defined?)
Thanks
N
|