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 t

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 #include #include int main(void) { fpsetround(FP_RM); printf("%ld\n", lrint(-0.2)); fp

Re: Upgrade i386 to amd64

On Wed, Apr 6, 2011 at 6:36 PM, 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.) Upgrading like that is not supposed to work. Upgrades do not replace the contents of /etc, which does have ar

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

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 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

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)

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 Rep

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

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'

Re: vnds considerd harmful.

In , Thordur Bjornsson 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). >

Re: "no really, be quiet" mode for ping{,6}

On Wed, Apr 6, 2011 at 7:00 AM, Peter Hessler 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, wh

Re: "no really, be quiet" mode for ping{,6}

On Wed, Apr 6, 2011 at 6:30 AM, 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. B Not quiet in the "only show me > :>headers" way that the original author thought was cu

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

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: Login using your standard use

Re: pmap prefer diff

> Date: Wed, 6 Apr 2011 14:15:50 +0200 > From: Ariane van der Steldt > > 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 > > > So it turns out that my allocator is not capable of handling the > > > pmap_

Re: rc.subr: print result of the "reload" command

On Wed, Apr 06, 2011 at 03:24:12PM +0200, Antoine Jacoutot wrote: > 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... I'm in total agreeme

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 defini

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 vis

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 ar

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 th

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

Re: rc.subr: print result of the "reload" command

On Wed, 6 Apr 2011, Piotr Sikora wrote: > 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 cus

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

Re: rc.subr: print result of the "reload" command

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 v

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)

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 tha

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

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

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

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

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 rega

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 ===

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 > > 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 > >

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: > > > >

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.spacehoppe

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 >

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 sp

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

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 co

Re: pmap prefer diff

> Date: Tue, 5 Apr 2011 18:42:47 +0200 > From: Ariane van der Steldt > > 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

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

Re: "no really, be quiet" mode for ping{,6}

On Tue, Apr 5, 2011 at 10:06 PM, 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, her