Reflex y SemiPro - Mejor precio del mercado
USD 898 Nikon D5000 Kit Caacute;mara digital reacute;flex de objetivos intercambiables / Sensor de imaacute;gen CMOS / Tamantilde;o 23,60 x15,80mm / Montura Nikon - Kit 18-55 / Pantalla TFT de 2,70 USD 840 NikonD3100 Kit Caacute;marareacute;flex digital de objetivos intercambiables Sensor de imagen Tipo CMOS / Tamantilde;o 23.10 x 15.40 mm / Filtro de color RGB / Resolucioacute;n 14.8 MPUSD687 FUJIFILM FINEPIX HS10 Tipo compacta, visor electroacute;nico / Sensor CMOS de 10,30 MP efectivos / Objetivo (en 35 mm) 24,0 - 720,0 mm / Zoom 30x (oacute;ptico) / 2x (digital) / Soportes compatibles SD Card, SDHC / Pantalla LCD de 3,00 pulgadas
Re: traceroute TOS
Thanks, useful(at least for me).
On Apr 5, 2011, at 5:57 PM, Stuart Henderson wrote:
On 2011/04/05 16:51, Stuart Henderson wrote:
if -t is used, display a notice when the TOS changes en-route.
ok?
oh, it's better with a (contrived) example:
$ traceroute -nt 7 naiad
traceroute to naiad.spacehopper.org (195.95.187.35), 64 hops max, 40 byte
packets
1 85.158.44.145 0.441 ms (TOS=33!) 0.328 ms 0.396 ms
2 193.178.223.245 14.637 ms 15.213 ms 15.466 ms
3 194.39.143.145 16.600 ms 15.468 ms 16.206 ms
4 194.39.143.205 16.483 ms 16.210 ms 15.843 ms
5 193.203.5.182 17.475 ms 16.708 ms 16.986 ms
6 195.95.187.248 17.211 ms (TOS=4!) 16.460 ms 16.468 ms
7 195.95.187.35 27.99 ms 16.207 ms 17.467 ms
Index: traceroute.8
===
RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v
retrieving revision 1.44
diff -u -p -r1.44 traceroute.8
--- traceroute.8 8 Jul 2010 20:23:03 - 1.44
+++ traceroute.8 5 Apr 2011 15:50:38 -
@@ -177,6 +177,8 @@ in probe packets to the following value
The value must be a decimal integer in the range 0 to 255.
This option can be used to
see if different types-of-service result in different paths.
+If this option is used, changes to the type-of-service in the
+returned packets are displayed.
(If you are not running a
.Bx 4.3 tahoe
or later system, this may be academic since the normal network
@@ -384,6 +386,8 @@ ever occur and the associated gateway is
(destination network or host unreachable for TOS),
.Sy !code
(other ICMP unreachable code).
+.Sy TOS=xxx
+(TOS bit in returned packet differs from last hop).
If almost all the probes result in some kind of unreachable,
.Nm
will give up and exit.
Index: traceroute.c
===
RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v
retrieving revision 1.74
diff -u -p -r1.74 traceroute.c
--- traceroute.c 22 Mar 2011 10:16:23 - 1.74
+++ traceroute.c 5 Apr 2011 15:50:38 -
@@ -293,11 +293,13 @@ main(int argc, char *argv[])
int mib[4] = { CTL_NET, PF_INET, IPPROTO_IP, IPCTL_DEFTTL };
int ttl_flag = 0, incflag = 1, protoset = 0, sump = 0;
int ch, i, lsrr = 0, on = 1, probe, seq = 0, tos = 0;
+int last_tos, tos_returned;
size_t size = sizeof(max_ttl);
struct sockaddr_in from, to;
struct hostent *hp;
u_int32_t tmprnd;
-struct ip *ip;
+struct ip *ip, *inner_ip;
+struct icmp *icp;
u_int8_t ttl;
char *ep;
const char *errstr;
@@ -427,7 +429,7 @@ main(int argc, char *argv[])
l = strtol(optarg, ep, 10);
if (errno || !*optarg || *ep || l 0 || l 255)
errx(1, tos must be 0 to 255.);
-tos = (int)l;
+last_tos = tos = (int)l;
break;
case 'v':
verbose++;
@@ -636,9 +638,21 @@ main(int argc, char *argv[])
++got_there;
break;
}
+
+icp = (struct icmp *) (((u_char
*)ip)+(ip-ip_hl2));
+inner_ip = (struct ip *) (((u_char *)icp)+8);
+
+tos_returned = inner_ip-ip_tos;
+
+if (tos_returned != last_tos)
+printf ( (TOS=%d!), tos_returned);
+
+last_tos = tos_returned;
+
/* time exceeded in transit */
if (i == -1)
break;
+
code = i - 1;
switch (code) {
case ICMP_UNREACH_PORT:
Re: pmap prefer diff
Date: Tue, 5 Apr 2011 18:42:47 +0200 From: Ariane van der Steldt ari...@stack.nl Hi, So it turns out that my allocator is not capable of handling the pmap_prefer horror. This diff exports the actual parameters of pmap_prefer, so I can make the allocator deal with this intelligently. I need compile tests on: - arm - hppa - hppa64 - m68k - mips64 - sh - sparc - sparc64 Since the code is not actually called, it should not affect running of kernels. Ok? Fine with me. With this, can't we completely get rid of the PMAP_PREFER? Index: arch//arm/include/pmap.h === RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v retrieving revision 1.17 diff -u -d -p -r1.17 pmap.h --- arch//arm/include/pmap.h 23 Mar 2011 16:54:34 - 1.17 +++ arch//arm/include/pmap.h 5 Apr 2011 16:30:58 - @@ -620,6 +620,14 @@ vaddr_t pmap_prefer(vaddr_t, vaddr_t); extern uint32_t pmap_alias_dist; extern uint32_t pmap_alias_bits; + +/* pmap prefer alias alignment. */ +#define PMAP_PREFER_ALIGN() (pmap_alias_dist) +/* pmap prefer offset withing alignment. */ +#define PMAP_PREFER_OFFSET(of) \ +(PMAP_PREFER_ALIGN() == 0 ? 0 : ((of) (PMAP_PREFER_ALIGN() - 1))) + + #endif /* _LOCORE */ #endif /* _KERNEL */ Index: arch//hppa/include/pmap.h === RCS file: /cvs/src/sys/arch/hppa/include/pmap.h,v retrieving revision 1.40 diff -u -d -p -r1.40 pmap.h --- arch//hppa/include/pmap.h 26 Dec 2010 15:40:59 - 1.40 +++ arch//hppa/include/pmap.h 5 Apr 2011 16:30:59 - @@ -101,6 +101,11 @@ pmap_prefer(vaddr_t offs, vaddr_t hint) return pmap_prefer_hint; } +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (HPPA_PGALIAS) +/* pmap prefer offset within alignment */ +#define PMAP_PREFER_OFFSET(of) ((of) HPPA_PGAOFF) + #define pmap_sid2pid(s) (((s) + 1) 1) #define pmap_kernel()(kernel_pmap_store) #define pmap_resident_count(pmap) ((pmap)-pm_stats.resident_count) Index: arch//hppa64/include/pmap.h === RCS file: /cvs/src/sys/arch/hppa64/include/pmap.h,v retrieving revision 1.4 diff -u -d -p -r1.4 pmap.h --- arch//hppa64/include/pmap.h 26 Dec 2010 15:40:59 - 1.4 +++ arch//hppa64/include/pmap.h 5 Apr 2011 16:30:59 - @@ -68,6 +68,11 @@ pmap_prefer(vaddr_t offs, vaddr_t hint) return pmap_prefer_hint; } +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (HPPA_PGALIAS) +/* pmap prefer offset within alignment */ +#define PMAP_PREFER_OFFSET(of) ((of) HPPA_PGAOFF) + #define PMAP_GROWKERNEL #define PMAP_STEAL_MEMORY Index: arch//m68k/include/pmap_motorola.h === RCS file: /cvs/src/sys/arch/m68k/include/pmap_motorola.h,v retrieving revision 1.22 diff -u -d -p -r1.22 pmap_motorola.h --- arch//m68k/include/pmap_motorola.h23 Mar 2011 16:54:35 - 1.22 +++ arch//m68k/include/pmap_motorola.h5 Apr 2011 16:30:59 - @@ -139,6 +139,12 @@ void pmap_kenter_cache(vaddr_t, paddr_t, #ifdef M68K_MMU_HP vaddr_t pmap_prefer(vaddr_t, vaddr_t); #define PMAP_PREFER(foff, va) pmap_prefer((foff), (va)) + +extern int pmap_aliasmask; /* separation at which VA aliasing is ok */ +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (pmap_aliasmask ? pmap_aliasmask + 1 : 0) +/* pmap prefer offset */ +#define PMAP_PREFER_OFFSET(of) ((of) pmap_aliasmask) #endif #endif /* _KERNEL */ Index: arch//m68k/m68k/pmap_motorola.c === RCS file: /cvs/src/sys/arch/m68k/m68k/pmap_motorola.c,v retrieving revision 1.59 diff -u -d -p -r1.59 pmap_motorola.c --- arch//m68k/m68k/pmap_motorola.c 6 Dec 2010 20:57:16 - 1.59 +++ arch//m68k/m68k/pmap_motorola.c 5 Apr 2011 16:30:59 - @@ -276,9 +276,6 @@ vaddr_t virtual_end;/* VA of last avai TAILQ_HEAD(pv_page_list, pv_page) pv_page_freelist; int pv_nfree; -#if defined(M68K_MMU_HP) -extern int pmap_aliasmask; /* separation at which VA aliasing is ok */ -#endif #if defined(M68040) || defined(M68060) int protostfree;/* prototype (default) free ST map */ #endif Index: arch//mips64/include/pmap.h === RCS file: /cvs/src/sys/arch/mips64/include/pmap.h,v retrieving revision 1.25 diff -u -d -p -r1.25 pmap.h --- arch//mips64/include/pmap.h 23 Mar 2011 16:54:36 - 1.25 +++ arch//mips64/include/pmap.h 5 Apr 2011 16:30:59 - @@ -125,6 +125,13 @@ extern struct pmap *const kernel_pmap_pt #define
Re: pmap prefer diff
On Tue, Apr 05, 2011 at 06:42:47PM +0200, Ariane van der Steldt wrote: Hi, So it turns out that my allocator is not capable of handling the pmap_prefer horror. This diff exports the actual parameters of pmap_prefer, so I can make the allocator deal with this intelligently. I need compile tests on: - arm - hppa - hppa64 - m68k - mips64 - sh - sparc - sparc64 Since the code is not actually called, it should not affect running of kernels. Ok? -- Ariane Compiles fine on sh with a small tweak of using vaddr_t pmap_prefer_align(void); instead of vaddr_t pmap_prefer_align(); Index: arch//arm/include/pmap.h === RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v retrieving revision 1.17 diff -u -d -p -r1.17 pmap.h --- arch//arm/include/pmap.h 23 Mar 2011 16:54:34 - 1.17 +++ arch//arm/include/pmap.h 5 Apr 2011 16:30:58 - @@ -620,6 +620,14 @@ vaddr_t pmap_prefer(vaddr_t, vaddr_t); extern uint32_t pmap_alias_dist; extern uint32_t pmap_alias_bits; + +/* pmap prefer alias alignment. */ +#define PMAP_PREFER_ALIGN() (pmap_alias_dist) +/* pmap prefer offset withing alignment. */ +#define PMAP_PREFER_OFFSET(of) \ +(PMAP_PREFER_ALIGN() == 0 ? 0 : ((of) (PMAP_PREFER_ALIGN() - 1))) + + #endif /* _LOCORE */ #endif /* _KERNEL */ Index: arch//hppa/include/pmap.h === RCS file: /cvs/src/sys/arch/hppa/include/pmap.h,v retrieving revision 1.40 diff -u -d -p -r1.40 pmap.h --- arch//hppa/include/pmap.h 26 Dec 2010 15:40:59 - 1.40 +++ arch//hppa/include/pmap.h 5 Apr 2011 16:30:59 - @@ -101,6 +101,11 @@ pmap_prefer(vaddr_t offs, vaddr_t hint) return pmap_prefer_hint; } +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (HPPA_PGALIAS) +/* pmap prefer offset within alignment */ +#define PMAP_PREFER_OFFSET(of) ((of) HPPA_PGAOFF) + #define pmap_sid2pid(s) (((s) + 1) 1) #define pmap_kernel()(kernel_pmap_store) #define pmap_resident_count(pmap) ((pmap)-pm_stats.resident_count) Index: arch//hppa64/include/pmap.h === RCS file: /cvs/src/sys/arch/hppa64/include/pmap.h,v retrieving revision 1.4 diff -u -d -p -r1.4 pmap.h --- arch//hppa64/include/pmap.h 26 Dec 2010 15:40:59 - 1.4 +++ arch//hppa64/include/pmap.h 5 Apr 2011 16:30:59 - @@ -68,6 +68,11 @@ pmap_prefer(vaddr_t offs, vaddr_t hint) return pmap_prefer_hint; } +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (HPPA_PGALIAS) +/* pmap prefer offset within alignment */ +#define PMAP_PREFER_OFFSET(of) ((of) HPPA_PGAOFF) + #define PMAP_GROWKERNEL #define PMAP_STEAL_MEMORY Index: arch//m68k/include/pmap_motorola.h === RCS file: /cvs/src/sys/arch/m68k/include/pmap_motorola.h,v retrieving revision 1.22 diff -u -d -p -r1.22 pmap_motorola.h --- arch//m68k/include/pmap_motorola.h23 Mar 2011 16:54:35 - 1.22 +++ arch//m68k/include/pmap_motorola.h5 Apr 2011 16:30:59 - @@ -139,6 +139,12 @@ void pmap_kenter_cache(vaddr_t, paddr_t, #ifdef M68K_MMU_HP vaddr_t pmap_prefer(vaddr_t, vaddr_t); #define PMAP_PREFER(foff, va) pmap_prefer((foff), (va)) + +extern int pmap_aliasmask; /* separation at which VA aliasing is ok */ +/* pmap prefer alignment */ +#define PMAP_PREFER_ALIGN() (pmap_aliasmask ? pmap_aliasmask + 1 : 0) +/* pmap prefer offset */ +#define PMAP_PREFER_OFFSET(of) ((of) pmap_aliasmask) #endif #endif /* _KERNEL */ Index: arch//m68k/m68k/pmap_motorola.c === RCS file: /cvs/src/sys/arch/m68k/m68k/pmap_motorola.c,v retrieving revision 1.59 diff -u -d -p -r1.59 pmap_motorola.c --- arch//m68k/m68k/pmap_motorola.c 6 Dec 2010 20:57:16 - 1.59 +++ arch//m68k/m68k/pmap_motorola.c 5 Apr 2011 16:30:59 - @@ -276,9 +276,6 @@ vaddr_t virtual_end;/* VA of last avai TAILQ_HEAD(pv_page_list, pv_page) pv_page_freelist; int pv_nfree; -#if defined(M68K_MMU_HP) -extern int pmap_aliasmask; /* separation at which VA aliasing is ok */ -#endif #if defined(M68040) || defined(M68060) int protostfree;/* prototype (default) free ST map */ #endif Index: arch//mips64/include/pmap.h === RCS file: /cvs/src/sys/arch/mips64/include/pmap.h,v retrieving revision 1.25 diff -u -d -p -r1.25 pmap.h --- arch//mips64/include/pmap.h 23 Mar 2011 16:54:36 - 1.25 +++ arch//mips64/include/pmap.h 5 Apr 2011 16:30:59 - @@ -125,6 +125,13 @@ extern
Re: no really, be quiet mode for ping{,6}
On Wed, 6 Apr 2011, Peter Hessler wrote: Sometimes I want ping to be quiet. Not quiet in the only show me headers way that the original author thought was cute, but in the don't show me anything way, so cron doesn't spam me with useless crap. So, in honor of that, here is a patch to add -Q to ping and ping6. What is the advantage of another button over redirecting stdout and error to /dev/null? Is the completely quiet ping used so often? Regards, David
Re: no really, be quiet mode for ping{,6}
On 2011 Apr 06 (Wed) at 12:47:40 +0200 (+0200), David Vasek wrote: :On Wed, 6 Apr 2011, Peter Hessler wrote: : :Sometimes I want ping to be quiet. Not quiet in the only show me :headers way that the original author thought was cute, but in the :don't show me anything way, so cron doesn't spam me with useless :crap. : :So, in honor of that, here is a patch to add -Q to ping and ping6. : :What is the advantage of another button over redirecting stdout and :error to /dev/null? Is the completely quiet ping used so often? : :Regards, :David : I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. I'm scratching an itch, here. -- It's the thought, if any, that counts!
Re: no really, be quiet mode for ping{,6}
On 2011-04-06 13.00, Peter Hessler wrote: On 2011 Apr 06 (Wed) at 12:47:40 +0200 (+0200), David Vasek wrote: :On Wed, 6 Apr 2011, Peter Hessler wrote: :Sometimes I want ping to be quiet. Not quiet in the only show me :headers way that the original author thought was cute, but in the :don't show me anything way, so cron doesn't spam me with useless :crap. :So, in honor of that, here is a patch to add -Q to ping and ping6. : :What is the advantage of another button over redirecting stdout and :error to /dev/null? Is the completely quiet ping used so often? I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. I'm scratching an itch, here. Personally, I see no problem redirecting output to /dev/null in scripts. In fact, I'd probably continue to do that even with a really quiet switch because it is the portable way to do it. (Ok, ping isn't the best command to use that argument with, since no two ping implementations seem to have the same set of switches, but generally speaking.) So, to add a switch whose sole purpose in life is to make scripting easier would be pointless to anyone who needs to be able to run their script in an environment other than OpenBSD. I'm not saying don't do it, I'm just saying I myself see no use for it other than the bloat value. :-) Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: traceroute TOS
On Tue, Apr 05, 2011 at 04:57:30PM +0100, Stuart Henderson wrote:
On 2011/04/05 16:51, Stuart Henderson wrote:
if -t is used, display a notice when the TOS changes en-route.
ok?
oh, it's better with a (contrived) example:
$ traceroute -nt 7 naiad
traceroute to naiad.spacehopper.org (195.95.187.35), 64 hops max, 40 byte
packets
1 85.158.44.145 0.441 ms (TOS=33!) 0.328 ms 0.396 ms
2 193.178.223.245 14.637 ms 15.213 ms 15.466 ms
3 194.39.143.145 16.600 ms 15.468 ms 16.206 ms
4 194.39.143.205 16.483 ms 16.210 ms 15.843 ms
5 193.203.5.182 17.475 ms 16.708 ms 16.986 ms
6 195.95.187.248 17.211 ms (TOS=4!) 16.460 ms 16.468 ms
7 195.95.187.35 27.99 ms 16.207 ms 17.467 ms
Diff looks good. What I don't like to specify and display the TOS as
decimal since I have no idea what decimal numbers are which TOS/DiffServ
Code points. No that is porbably a different diff, so OK claudio@ for this
one.
Index: traceroute.8
===
RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v
retrieving revision 1.44
diff -u -p -r1.44 traceroute.8
--- traceroute.88 Jul 2010 20:23:03 - 1.44
+++ traceroute.85 Apr 2011 15:50:38 -
@@ -177,6 +177,8 @@ in probe packets to the following value
The value must be a decimal integer in the range 0 to 255.
This option can be used to
see if different types-of-service result in different paths.
+If this option is used, changes to the type-of-service in the
+returned packets are displayed.
(If you are not running a
.Bx 4.3 tahoe
or later system, this may be academic since the normal network
@@ -384,6 +386,8 @@ ever occur and the associated gateway is
(destination network or host unreachable for TOS),
.Sy !code
(other ICMP unreachable code).
+.Sy TOS=xxx
+(TOS bit in returned packet differs from last hop).
If almost all the probes result in some kind of unreachable,
.Nm
will give up and exit.
Index: traceroute.c
===
RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v
retrieving revision 1.74
diff -u -p -r1.74 traceroute.c
--- traceroute.c22 Mar 2011 10:16:23 - 1.74
+++ traceroute.c5 Apr 2011 15:50:38 -
@@ -293,11 +293,13 @@ main(int argc, char *argv[])
int mib[4] = { CTL_NET, PF_INET, IPPROTO_IP, IPCTL_DEFTTL };
int ttl_flag = 0, incflag = 1, protoset = 0, sump = 0;
int ch, i, lsrr = 0, on = 1, probe, seq = 0, tos = 0;
+ int last_tos, tos_returned;
size_t size = sizeof(max_ttl);
struct sockaddr_in from, to;
struct hostent *hp;
u_int32_t tmprnd;
- struct ip *ip;
+ struct ip *ip, *inner_ip;
+ struct icmp *icp;
u_int8_t ttl;
char *ep;
const char *errstr;
@@ -427,7 +429,7 @@ main(int argc, char *argv[])
l = strtol(optarg, ep, 10);
if (errno || !*optarg || *ep || l 0 || l 255)
errx(1, tos must be 0 to 255.);
- tos = (int)l;
+ last_tos = tos = (int)l;
break;
case 'v':
verbose++;
@@ -636,9 +638,21 @@ main(int argc, char *argv[])
++got_there;
break;
}
+
+ icp = (struct icmp *) (((u_char
*)ip)+(ip-ip_hl2));
+ inner_ip = (struct ip *) (((u_char *)icp)+8);
+
+ tos_returned = inner_ip-ip_tos;
+
+ if (tos_returned != last_tos)
+ printf ( (TOS=%d!), tos_returned);
+
+ last_tos = tos_returned;
+
/* time exceeded in transit */
if (i == -1)
break;
+
code = i - 1;
switch (code) {
case ICMP_UNREACH_PORT:
--
:wq Claudio
Re: traceroute TOS
On 2011/04/06 13:35, Claudio Jeker wrote: On Tue, Apr 05, 2011 at 04:57:30PM +0100, Stuart Henderson wrote: On 2011/04/05 16:51, Stuart Henderson wrote: if -t is used, display a notice when the TOS changes en-route. ok? oh, it's better with a (contrived) example: $ traceroute -nt 7 naiad traceroute to naiad.spacehopper.org (195.95.187.35), 64 hops max, 40 byte packets 1 85.158.44.145 0.441 ms (TOS=33!) 0.328 ms 0.396 ms 2 193.178.223.245 14.637 ms 15.213 ms 15.466 ms 3 194.39.143.145 16.600 ms 15.468 ms 16.206 ms 4 194.39.143.205 16.483 ms 16.210 ms 15.843 ms 5 193.203.5.182 17.475 ms 16.708 ms 16.986 ms 6 195.95.187.248 17.211 ms (TOS=4!) 16.460 ms 16.468 ms 7 195.95.187.35 27.99 ms 16.207 ms 17.467 ms Diff looks good. What I don't like to specify and display the TOS as decimal since I have no idea what decimal numbers are which TOS/DiffServ Code points. No that is porbably a different diff, so OK claudio@ for this one. I agree, I think we would also want to be able to use these in -t (-t lowdelay, -t af11, etc.)
Re: pmap prefer diff
On Wed, Apr 06, 2011 at 10:31:14AM +0200, Mark Kettenis wrote: Date: Tue, 5 Apr 2011 18:42:47 +0200 From: Ariane van der Steldt ari...@stack.nl So it turns out that my allocator is not capable of handling the pmap_prefer horror. This diff exports the actual parameters of pmap_prefer, so I can make the allocator deal with this intelligently. Fine with me. With this, can't we completely get rid of the PMAP_PREFER? You are right. Should I adapt the diff for that? -- Ariane
rc.subr: print result of the reload command
Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
Best regards,
Piotr Sikora piotr.sik...@frickle.com
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.33
diff -u -r1.33 rc.subr
--- rc.subr 6 Apr 2011 06:09:28 - 1.33
+++ rc.subr 6 Apr 2011 11:38:57 -
@@ -89,7 +89,8 @@
fi
;;
reload)
- rc_do rc_check rc_do rc_reload
+ rc_do rc_check \
+ ( rc_do rc_reload rc_print ok || rc_print failed )
;;
restart)
/etc/rc.d/${_name} stop /etc/rc.d/${_name} start
Re: rc.subr: print result of the reload command
On Sun, 3 Apr 2011, Piotr Sikora wrote:
Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
No, this was left out on purpose. If you want to see stderr, use
RC_DEBUG.
Best regards,
Piotr Sikora piotr.sik...@frickle.com
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.33
diff -u -r1.33 rc.subr
--- rc.subr 6 Apr 2011 06:09:28 - 1.33
+++ rc.subr 6 Apr 2011 11:38:57 -
@@ -89,7 +89,8 @@
fi
;;
reload)
- rc_do rc_check rc_do rc_reload
+ rc_do rc_check \
+ ( rc_do rc_reload rc_print ok || rc_print failed )
;;
restart)
/etc/rc.d/${_name} stop /etc/rc.d/${_name} start
--
Antoine
Re: rc.subr: print result of the reload command
Hi, No, this was left out on purpose. If you want to see stderr, use RC_DEBUG. But this patch doesn't bring back stderr, it just prints daemon(ok/failed). This is already present in start, restart and stop commands, why should reload be any different? Best regards, Piotr Sikora piotr.sik...@frickle.com
Re: rc.subr: print result of the reload command
On 2011/04/03 18:04, Piotr Sikora wrote:
Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
This doesn't usually indicate that the reload was successful,
just that you were able to send the process a SIGHUP. As such I think
printing ok here gives a false sense of security.
Best regards,
Piotr Sikora piotr.sik...@frickle.com
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.33
diff -u -r1.33 rc.subr
--- rc.subr 6 Apr 2011 06:09:28 - 1.33
+++ rc.subr 6 Apr 2011 11:38:57 -
@@ -89,7 +89,8 @@
fi
;;
reload)
- rc_do rc_check rc_do rc_reload
+ rc_do rc_check \
+ ( rc_do rc_reload rc_print ok || rc_print failed )
;;
restart)
/etc/rc.d/${_name} stop /etc/rc.d/${_name} start
Re: rc.subr: print result of the reload command
On Wed, 6 Apr 2011, Piotr Sikora wrote: Hi, No, this was left out on purpose. If you want to see stderr, use RC_DEBUG. But this patch doesn't bring back stderr, it just prints daemon(ok/failed). Ok but in your former mail you said since daemon's stderr is suppressed So if you're looking for stderr, use RC_DEBUG. This is already present in start, restart and stop commands, why should reload be any different? Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. -- Antoine
Re: rc.subr: print result of the reload command
Hi, This doesn't usually indicate that the reload was successful, just that you were able to send the process a SIGHUP. As such I think printing ok here gives a false sense of security. Yes and no... Some daemons, like nginx, have custom rc_reload command that actually does useful stuff and sanity checking. Example: # /etc/rc.d/nginx reload nginx(failed) # RC_DEBUG=1 /etc/rc.d/nginx reload doing rc_check doing rc_reload [emerg]: unknown directive test in /etc/nginx/nginx.conf:1 nginx(failed) Without nginx(failed) output, most people would assume that nginx reloaded successfully. Granted, there are only 8 ports with custom rc_reload logic, but why should they suffer? Best regards, Piotr Sikora piotr.sik...@frickle.com
Re: rc.subr: print result of the reload command
Hi, Ok but in your former mail you said since daemon's stderr is suppressed So if you're looking for stderr, use RC_DEBUG. What I meant is that since stderr is suppressed (we don't print daemon's output), printing deamon(ok/failed) is the next best thing we can do to inform users that command did or did not succeed. Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. Yes, but there are 8 ports that have custom rc_reload logic. Best regards, Piotr Sikora piotr.sik...@frickle.com
Re: rc.subr: print result of the reload command
On Wed, 6 Apr 2011, Piotr Sikora wrote: Hi, Ok but in your former mail you said since daemon's stderr is suppressed So if you're looking for stderr, use RC_DEBUG. What I meant is that since stderr is suppressed (we don't print daemon's output), printing deamon(ok/failed) is the next best thing we can do to inform users that command did or did not succeed. Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. Yes, but there are 8 ports that have custom rc_reload logic. What does this have to do with anything? -- Antoine
Re: rc.subr: print result of the reload command
On Wed, 6 Apr 2011, Piotr Sikora wrote: Hi, Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. Yes, but there are 8 ports that have custom rc_reload logic. What does this have to do with anything? Uhm... They *do* return correct exit value in case of success / error, which means that returning daemon(ok/failed) in their case is useful. They are exceptions. They don't use the default. -- Antoine
Re: rc.subr: print result of the reload command
On 2011/04/06 15:09, Piotr Sikora wrote: Hi, Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. Yes, but there are 8 ports that have custom rc_reload logic. What does this have to do with anything? Uhm... They *do* return correct exit value in case of success / error, which means that returning daemon(ok/failed) in their case is useful. The only way I'd accept this is if we had something like reload_can_fail, and only print ok/fail if a particular script supports it. However it does add complexity (and inevitable why does daemon X say ok/fail when it reloads but other daemons don't questions...) so I'm not sure if we want that.
Re: rc.subr: print result of the reload command
On Wed, 6 Apr 2011, Stuart Henderson wrote: On 2011/04/06 15:09, Piotr Sikora wrote: Hi, Because it is next to impossible to get a correct return. By default, all we can check is that SIGHUP was successfull or not, that's it. Yes, but there are 8 ports that have custom rc_reload logic. What does this have to do with anything? Uhm... They *do* return correct exit value in case of success / error, which means that returning daemon(ok/failed) in their case is useful. The only way I'd accept this is if we had something like reload_can_fail, and only print ok/fail if a particular script supports it. However it does add complexity (and inevitable why does daemon X say ok/fail when it reloads but other daemons don't questions...) so I'm not sure if we want that. I would really not be happy with that. I think so far we managed to stay super small and simple and I don't really want to add variable/knob for each possible situation. Although others may disagree... -- Antoine
Re: rc.subr: print result of the reload command
Hi, Otherwise you can end up with foobar(ok) when in fact the daemon failed to reload. We're ending up with $? = 0 from reload command anyway. daemon(ok/failed) is only visual representation of that. So we have to choose between hundreds of daemons that are using the default or 8 that are not... hmm tough choice ;) There are only 60 daemons that use .rc scripts, not hundreds. The best compromise is to not print anything instead of printing what _may_ be true. But you are doing this already. You can get foobar(ok) from the start command even if foo daemon fails to start later in the process (ports already in use, etc). What about custom RC_RELOAD_OUTPUT variable that would print result for ports with custom logic? Would that work for you? Best regards, Piotr Sikora piotr.sik...@frickle.com
Re: rc.subr: print result of the reload command
On Wed, 6 Apr 2011, Piotr Sikora wrote: Hi, Otherwise you can end up with foobar(ok) when in fact the daemon failed to reload. We're ending up with $? = 0 from reload command anyway. daemon(ok/failed) is only visual representation of that. Exactly. But when I see a visual representation of OK, I assume it reloaded ok. So we have to choose between hundreds of daemons that are using the default or 8 that are not... hmm tough choice ;) There are only 60 daemons that use .rc scripts, not hundreds. Yet. The best compromise is to not print anything instead of printing what _may_ be true. But you are doing this already. You can get foobar(ok) from the start command even if foo daemon fails to start later in the process (ports already in use, etc). Yes and it was discussed and accepted because we do not want to rc_wait on startup. That is not a reason to have the same defect everywhere. Also during boot sequence, the rc scripts will probably not print anything (besides from the usual daemon name) anyway in a near future. What about custom RC_RELOAD_OUTPUT variable that would print result for ports with custom logic? Would that work for you? I would like to prevent adding knobs when at all possible. -- Antoine
Re: rc.subr: print result of the reload command
Hi,
What about custom RC_RELOAD_OUTPUT variable that would print result for
ports
with custom logic? Would that work for you?
I would like to prevent adding knobs when at all possible.
To be honest, I kind of agree.
Last try:
What about printing only foobar(failed)? By definition, it would be printed
only for ports with custom rc_reload logic.
Best regards,
Piotr Sikora piotr.sik...@frickle.com
Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.33
diff -u -r1.33 rc.subr
--- rc.subr 6 Apr 2011 06:09:28 - 1.33
+++ rc.subr 6 Apr 2011 13:40:42 -
@@ -89,7 +89,7 @@
fi
;;
reload)
- rc_do rc_check rc_do rc_reload
+ rc_do rc_check ( rc_do rc_reload || rc_print failed )
;;
restart)
/etc/rc.d/${_name} stop /etc/rc.d/${_name} start
Re: pmap prefer diff
Date: Wed, 6 Apr 2011 14:15:50 +0200 From: Ariane van der Steldt ari...@stack.nl On Wed, Apr 06, 2011 at 10:31:14AM +0200, Mark Kettenis wrote: Date: Tue, 5 Apr 2011 18:42:47 +0200 From: Ariane van der Steldt ari...@stack.nl So it turns out that my allocator is not capable of handling the pmap_prefer horror. This diff exports the actual parameters of pmap_prefer, so I can make the allocator deal with this intelligently. Fine with me. With this, can't we completely get rid of the PMAP_PREFER? You are right. Should I adapt the diff for that? We can clean that up later.
Summary of junk emails blocked - 1 Junk Emails Blocked
Junk Box Summary for: tech@openbsd.org The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 1 days. To retrieve any of these messages, visit your Junk Box at: http://192.168.1.253:10080 Login using your standard username/password combination. Junk Box Summary - fa...@gmail.com =?windows-1251?B?W8rIxcJdINTIzcDN0cjQzsLAzcjFINHS0M7I0s... - Junk blocking by SonicWALL
Merge viapm and viaenv drivers
Hi! Merge viapm and viaenv Pluse: - Add support SMBus for VT82C596, VT82C596B, VT82C686A, VT8231 - Add support ACPI timer for all VIA South Bridges Tested on: - VT82C596B (Gigabyte GA-6VXE7+) - VT82C686A (Neoware CA2) - VT8231 (HP T5700) - VT8235 (Neoware CA10) OK? -- Alexandr Shadchin Index: share/man/man4/Makefile === RCS file: /cvs/src/share/man/man4/Makefile,v retrieving revision 1.520 diff -u -p -r1.520 Makefile --- share/man/man4/Makefile 28 Mar 2011 15:25:37 - 1.520 +++ share/man/man4/Makefile 6 Apr 2011 16:34:10 - @@ -62,7 +62,7 @@ MAN= aac.4 ac97.4 acphy.4 \ urndis.4 urtw.4 urtwn.4 usb.4 usbf.4 uscanner.4 uslcom.4 uthum.4 \ uticom.4 utrh.4 uts.4 uvideo.4 uvisor.4 uvscom.4 uyap.4 utwitch.4 \ vether.4 vga.4 vgafb.4 vge.4 \ - viaenv.4 viapm.4 viasio.4 vic.4 video.4 vlan.4 vmt.4 vnd.4 vr.4 \ + viapm.4 viasio.4 vic.4 video.4 vlan.4 vmt.4 vnd.4 vr.4 \ vscsi.4 vte.4 \ watchdog.4 wb.4 wbenv.4 wbng.4 wbsd.4 wbsio.4 wd.4 wdc.4 we.4 \ wi.4tbl wpi.4 wscons.4 wsdisplay.4 wskbd.4 wsmouse.4 wsmux.4 \ Index: share/man/man4/pci.4 === RCS file: /cvs/src/share/man/man4/pci.4,v retrieving revision 1.301 diff -u -p -r1.301 pci.4 --- share/man/man4/pci.415 Jan 2011 04:35:34 - 1.301 +++ share/man/man4/pci.46 Apr 2011 16:34:10 - @@ -417,7 +417,7 @@ AMD K8 temperature sensor AMD K10 temperature sensor .It Xr pwdog 4 Quancom PWDOG1 watchdog timer device -.It Xr viaenv 4 +.It Xr viapm 4 VIA VT82C686A/VT8231 hardware monitor .It Xr wdt 4 ICS PCI-WDT500/501 watchdog timer device Index: share/man/man4/viaenv.4 === RCS file: share/man/man4/viaenv.4 diff -N share/man/man4/viaenv.4 --- share/man/man4/viaenv.4 31 May 2007 19:19:53 - 1.11 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,90 +0,0 @@ -.\$OpenBSD: viaenv.4,v 1.11 2007/05/31 19:19:53 jmc Exp $ -.\$NetBSD: viaenv.4,v 1.5 2001/09/11 23:18:55 wiz Exp $ -.\ -.\ Copyright (c) 2000 Johan Danielsson -.\ 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 author nor the names of any contributors may -.\be used to endorse or promote products derived from this -.\software without specific prior written permission. -.\ -.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 FOUNDATION 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. -.Dd $Mdocdate: May 31 2007 $ -.Dt VIAENV 4 -.Os -.Sh NAME -.Nm viaenv -.Nd VIA VT82C686A/VT8231 hardware monitor -.Sh SYNOPSIS -.Cd viaenv* at pci? -.Sh DESCRIPTION -The -.Nm -driver provides support for the hardware monitor and power management -timer in the -.Tn VIA -VT82C686A and VT8231 South Bridges. -The hardware monitor is used with the -.Xr sysctl 8 -interface. -.Pp -The device has 10 sensors: -.Bl -column Sensor Units Typical -offset indent -.It Sy Sensor Ta Sy Units Ta Sy Typical Use -.It Li TSENS1 Ta uK Ta CPU temperature -.It Li TSENS2 Ta uK Ta System temperature -.It Li TSENS3 Ta uK Ta Unknown -.It Li FAN1 Ta RPM Ta CPU fan -.It Li FAN2 Ta RPM Ta System fan -.It Li VSENS1 Ta uV DC Ta CPU core voltage (2.0V) -.It Li VSENS2 Ta uV DC Ta North Bridge core voltage (2.5V) -.It Li Vcore Ta uV DC Ta Internal core voltage (3.3V) -.It Li VSENS3 Ta uV DC Ta +5V -.It Li VSENS4 Ta uV DC Ta +12V -.El -.Pp -Sensor data is updated every 1.5 seconds. -.Sh SEE ALSO -.Xr sensorsd 8 , -.Xr sysctl 8 -.Sh HISTORY -The -.Nm -driver first appeared in -.Nx 1.5 . -.Ox -support was added in -.Ox 3.4 . -.Sh AUTHORS -.An -nosplit -The -.Nm -driver was written by -.An Johan Danielsson -and ported to -.Ox 3.4 -by -.An Alexander Yurchenko Aq
Re: no really, be quiet mode for ping{,6}
On Wed, Apr 6, 2011 at 6:30 AM, Peter Hessler phess...@openbsd.org wrote: On 2011 Apr 06 (Wed) at 12:47:40 +0200 (+0200), David Vasek wrote: :On Wed, 6 Apr 2011, Peter Hessler wrote: : :Sometimes I want ping to be quiet. B Not quiet in the only show me :headers way that the original author thought was cute, but in the :don't show me anything way, so cron doesn't spam me with useless :crap. : :So, in honor of that, here is a patch to add -Q to ping and ping6. : :What is the advantage of another button over redirecting stdout and :error to /dev/null? Is the completely quiet ping used so often? : :Regards, :David : I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. B I'm scratching an itch, here. -- It's the thought, if any, that counts! the shell was supposed to define the interface so that not every program had to recreate it and now ksh has a convenient short-hand: ping google.com - the homogeneous -q flags are as problematic as: tar xf - vs. tar xf /dev/stdin seems strange that it was decided to put the - alias inside every and each command that uses it instead of having distinct shorthand for stdout/in through the shell or fs
Re: no really, be quiet mode for ping{,6}
On Wed, Apr 6, 2011 at 7:00 AM, Peter Hessler phess...@openbsd.org wrote: I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. I'm scratching an itch, here. Sorry, I think I'm with the haters here. Quiet flags are for interactive use, where the normal volume of output is too much. If you're using a program in a script and only care about the exit code, output redirection is the standard answer. Otherwise, where does it end, a quiet flag for ls?
Re: vnds considerd harmful.
In http://marc.info/?l=openbsd-techm=130200205608892w=1, Thordur Bjornsson thib () openbsd ! org wrote: Now that I've disallowed swapping to vnd's the purpose of vnd (vs svnd) is suspect, it serves no purpose other then providing a different way of doing what svnd does (which imo, isn't even better). So, nuke vnds (keep svnds though!). This will make svndXn the same as vndXn etc. The idea is that in a few releases we'll simply remove the svnd0 notes. comments/ok ? Could you clarify the semantics of the in a few releases plan? That is, are you proposing that the in a few releases OpenBSD will have (a) vnd == today's svnd, (b) vnd == today's vnd, (c) vnd == some sort of merging of today's vnd and today's svnd, or (d) something else which hasn't occured to me yet I sort of think you're proposing (a), but I'm not entirely sure that I'm parsing your wording correctly... [Hmm, I wonder if my failure-to-parse is related to a recent bout of perl hashes holding references to anonymous hashes holding references to anonymous lists. :) ] thanks, ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
if_ath oerrors with multicast traffic
There is a correlation between netstat -I ath0 showing more Oerrs and multicast packets (e.g. CARP) leaving the interface. There is no apparent real problem since these frames are received just fine at the other end. The diff below stops the driver from doing this. Is this right? BTW, there doesn't seem to be any in-tree userland tool to print stats reported by the SIOCGATHSTATS ioctl. Is one available anywhere? Index: ath.c === RCS file: /cvs/src/sys/dev/ic/ath.c,v retrieving revision 1.91 diff -u -p -r1.91 ath.c --- ath.c 7 Sep 2010 16:21:42 - 1.91 +++ ath.c 6 Apr 2011 20:02:37 - @@ -2488,7 +2488,6 @@ ath_tx_proc(void *arg, int npending) if (bf-bf_id.id_node != NULL) ieee80211_rssadapt_lower_rate(ic, ni, an-an_rssadapt, bf-bf_id); - ifp-if_oerrors++; if (ds-ds_txstat.ts_status HAL_TXERR_XRETRY) sc-sc_stats.ast_tx_xretries++; if (ds-ds_txstat.ts_status HAL_TXERR_FIFO)
Upgrade i386 to amd64
Ran the upgrade from CD. Want to be sure that packages are OK. Is pkg_add -u sufficient? (It looks like nothing changed.) Thanks, Steven
Re: Upgrade i386 to amd64
On 2011/04/06 18:36, Steven R. Gerber wrote:
Ran the upgrade from CD.
Want to be sure that packages are OK.
Is pkg_add -u sufficient? (It looks like nothing changed.)
No, remove old packages and re-add them:
pkg_info -q ~/pkglist
pkg_delete /var/db/pkg/{.*,*}
pkg_add -zl ~/pkglist
Reply-To set to ports@.
Re: Upgrade i386 to amd64
On 2011-04-07 00:36, Steven R. Gerber wrote: Ran the upgrade from CD. Want to be sure that packages are OK. Is pkg_add -u sufficient? (It looks like nothing changed.) Thanks, Steven What about all the *.db files? They are incompatible between i368 and amd64 (/etc/(pwd|spwd).db, /var/db/spamd ...)
Re: no really, be quiet mode for ping{,6}
On Wed, Apr 06, 2011 at 03:19:00PM -0400, Ted Unangst wrote: On Wed, Apr 6, 2011 at 7:00 AM, Peter Hessler phess...@openbsd.org wrote: I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. I'm scratching an itch, here. Sorry, I think I'm with the haters here. Quiet flags are for interactive use, where the normal volume of output is too much. If you're using a program in a script and only care about the exit code, output redirection is the standard answer. Otherwise, where does it end, a quiet flag for ls? I am a big fan of -q (really quiet version) in scripts. But my script work is in the install media where every byte saved is a win. Ken
Comprar en China y Asia
Estimado/a Sr./a., Como brokers con experiencia en */importaciC3n o fabricaciC3n /*desde China, Asia y otros paises desde 1991, podemos ofrecerle 4 servicios basicos */en temas de importaciC3n o fabricacion:/* *Si aun no compra en Asia: * *COMPRAMOS PARA SU EMPRESA EN CHINA Y ASIA http://www.asasesores.com/index2.html * *Si ya compra en Asia: * *INSPECCIONES EN CHINA Y ASIA http://www.asasesores.com/index2.html * *GESTION DEL TRANSPORTE, ADUANAS, ETC., HASTA SU ALMACEN http://www.asasesores.com/index2.html * *GABINETES LEGALES EN CHINA Y ASIA http://www.asasesores.com/index2.html * En compras e importaciones para su empresa, nuestros honorarios solo son una pequeC1a comision, que suele estar al rededor del 5 % (entre el 3 y el 9%), segun el tipo de productos, y queda diluida en el coste final, ya que la mayoria de proveedores chinos son caros porque realmente solo son comerciales que, en algunos casos, incrementan el precio hasta el doble o mas del coste real alli..., funcionamos como su departamento de importacion externo. Dada nuestra experiencia y contactos, tenemos una amplia gama de proveedores en muy variados sectores, no obstante, podemos encontrar el producto que busca en pocos dias si no tuviesemos el proveedor que Ud. necesita. Tambien podemos realizarle cualquier tipo de inspeccion, analisis de productos, transporte hasta su empresa incluyendo aranceles y etc., o bien la gestion legal si ha tenido algun problema con sus proveedores. Asi pues, no lo dude, nuestro experto personal tanto en China como en nuestro pais le facilitara el C)xito en precios, gestion y rapidez para unos buenos resultados, y a un coste inapreciable. Pidanos algun producto concreto y le daremos precio para comparar. Quedamos a la espera de sus proximas noticias, entretanto reciba un cordial saludo. Atentamente, Albert Suros AS Asesores Llacuna. 162 08018 Barcelona Tel.: 93 219 21 10 Fax: 93 213 22 23 www.asasesores.com http://www.asasesores.com/ a...@asasesores.com mailto:a...@asasesores.com En cumplimiento con ley LSSI si no desea recibir nuestros email pulse en los siguientes enlaces para borrarse, modificar sus datos o aqadir una nueva direccion: Para modificar su direccion pulse: http://catalogofertas.com/PHP/?p=preferencesuid=8f56fdb5dd51190596be6bb2885fe463 Para redirigir los mensajes a otra direccion de email pulse: http://catalogofertas.com/PHP/?p=forwarduid=8f56fdb5dd51190596be6bb2885fe463mid=1 Para borrarse pulse:(OJO!!, SI TIENE SU DIRECCION REDIRIGIDA DESDE OTRA DIRECCION DEBE INDICAR LA ORIGINAL PARA BORRARSE) http://catalogofertas.com/PHP/?p=unsubscribeuid=8f56fdb5dd51190596be6bb2885fe463 Para modificar su direccion pulse: http://catalogofertas.com/PHP/?p=preferencesuid=8f56fdb5dd51190596be6bb2885fe463 Para redirigir los mensajes pulse: http://catalogofertas.com/PHP/?p=forwarduid=8f56fdb5dd51190596be6bb2885fe463mid=1 -- Powered by PHPlist, www.phplist.com -- [demime 1.01d removed an attachment of type image/png which had a name of powerphplist.png]
Re: Upgrade i386 to amd64
On Wed, Apr 6, 2011 at 6:36 PM, Steven R. Gerber sger...@gerber-systems.com wrote: Ran the upgrade from CD. Want to be sure that packages are OK. Is pkg_add -u sufficient? (It looks like nothing changed.) Upgrading like that is not supposed to work. Upgrades do not replace the contents of /etc, which does have architecture dependent files in it, and you are also left with stale i386 files sprinkled about. Do a clean install.
lrint fix
Our lrint, llrint, lrintf, llrintf always return 0 for inputs close
to 0. However, depending on the rounding mode, they should actually
return -1 or 1.
Here's my test case:
#include ieeefp.h
#include math.h
#include stdio.h
int
main(void)
{
fpsetround(FP_RM);
printf(%ld\n, lrint(-0.2));
fpsetround(FP_RP);
printf(%ld\n, lrint(0.2));
return (0);
}
It returns zero, however they should actually be -1, and 1. The
assumption that |1.0 * 2^exp| = 0, exp -1 cannot be made when we
round towards -inf or +inf.
If you're testing it on amd64 or i386 please note, that those
platforms are not affected--they use the assembly versions which do
the right thing.
Index: s_lrint.c
===
RCS file: /cvs/src/lib/libm/src/s_lrint.c,v
retrieving revision 1.1
diff -u -r1.1 s_lrint.c
--- s_lrint.c 25 Sep 2006 20:25:41 - 1.1
+++ s_lrint.c 7 Apr 2011 01:07:20 -
@@ -61,9 +61,6 @@
s = e DBL_EXPBITS;
e = (e 0x7ff) - DBL_EXP_BIAS;
- /* 1.0 x 2^-1 is the smallest number which can be rounded to 1 */
- if (e -1)
- return (0);
/* 1.0 x 2^31 (or 2^63) is already too large */
if (e = (int)RESTYPE_BITS - 1)
return (s ? RESTYPE_MIN : RESTYPE_MAX); /* ??? unspecified */
@@ -79,6 +76,9 @@
e = ((i0 20) 0x7ff) - DBL_EXP_BIAS;
i0 = 0xf;
i0 |= (1 20);
+
+ if (e 0)
+ return (0);
shift = e - DBL_FRACBITS;
if (shift =0)
Index: s_lrintf.c
===
RCS file: /cvs/src/lib/libm/src/s_lrintf.c,v
retrieving revision 1.1
diff -u -r1.1 s_lrintf.c
--- s_lrintf.c 25 Sep 2006 20:25:41 - 1.1
+++ s_lrintf.c 7 Apr 2011 01:10:19 -
@@ -61,9 +61,6 @@
s = e SNG_EXPBITS;
e = (e 0xff) - SNG_EXP_BIAS;
- /* 1.0 x 2^-1 is the smallest number which can be rounded to 1 */
- if (e -1)
- return (0);
/* 1.0 x 2^31 (or 2^63) is already too large */
if (e = (int)RESTYPE_BITS - 1)
return (s ? RESTYPE_MIN : RESTYPE_MAX); /* ??? unspecified */
@@ -81,6 +78,9 @@
e = ((i0 SNG_FRACBITS) 0xff) - SNG_EXP_BIAS;
i0 = 0x7f;
i0 |= (1 SNG_FRACBITS);
+
+ if (e 0)
+ return (0);
shift = e - SNG_FRACBITS;
if (shift =0)
Re: rthreads: fix sharing of signal stacks and actions
On 06/04/11 9:34 PM, Philip Guenther wrote:
Signal stacks are supposed to be per-thread, but they're currently in the
shared sigacts structure, so move them to struct proc. The SAS_ALTSTACK
flag can go away completely: it was always the inverse of the SS_DISABLE
flag on the sigstk, so just use that directly.
Similar for the values used during core dumping: ps_sig, ps_code, ps_type,
and ps_sigval: if we sleep during the run-up to coredumping, some other
thread (perhaps in a completely different process) might get in and change
them, so move them from sigacts to proc.
Similar for ps_oldmask and SAS_OLDMASK: sigsuspend() is per-rthread, so we
need to move that to the flags on struct proc. I rename the flag to
P_SIGSUSPEND to make it clearer what it's involved in.
Contrawise, p_sigignore, p_sigcatch, P_NOCLDSTOP, and P_NOCLDWAIT are
currently in struct proc, but they need to reflect the shared disposition
of the signals, so move them from struct proc to struct sigacts. This
requires a bit of glue in libkvm and the sysctl bits so that the
p_sigignore and p_sigcatch members of kinfo_proc structure are still
filled in.
Finally, ps_usertramp was old SunOS-compat stuff missed in the
COMPAT_SUNOS removal, so just kill it.
oks?
I take it this PF diff was not supposed to be in there.. ?
Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.738
diff -u -p -r1.738 pf.c
--- sys/net/pf.c6 Apr 2011 13:18:39 - 1.738
+++ sys/net/pf.c7 Apr 2011 01:22:42 -
@@ -313,7 +313,7 @@ RB_GENERATE(pf_state_tree, pf_state_key,
RB_GENERATE(pf_state_tree_id, pf_state,
entry_id, pf_state_compare_id);
-__inline int
+__inline __attribute__((__gnu_inline__)) int
pf_addr_compare(struct pf_addr *a, struct pf_addr *b, sa_family_t af)
{
switch (af) {
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
