Re: [ksh] [patch] Make "$@" POSIX-compliant with empty IFS

2016-03-23 Thread Theo Buehler
On Fri, Mar 04, 2016 at 11:29:38AM +0100, Dmitrij D. Czarkoff wrote: > Martijn Dekker said: > > So this patch makes quoted "$@" act according to the standard even when > > IFS is empty. Quoted "$*" is unchanged. For the unspecified (not > > standardised) cases of unquoted $@ and $*, this patch

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Theo de Raadt
> > Even if one day we fix the "browsers problem" in the thread > > library, I think this diff will remain necessary to handle > > processes calling sched_yield() in a loop, i.e. processes that are > > spinning. > > > Complete and utter hack: penalize processes or threads on > #system calls/time

[patch] www errata59.html - validation pass id rNNN - worthy?

2016-03-23 Thread lists
Tue, 15 Mar 2016 07:10:12 -0600 (MDT) Theo de Raadt > CVSROOT: /cvs > Module name: www > Changes by: dera...@cvs.openbsd.org 2016/03/15 07:10:12 > > Modified files: > . : errata57.html errata58.html errata59.html > > Log message: > release new

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread gwes
On 03/23/2016 18:58, Alexandre Ratchov wrote: On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: This doesn't only change the sched_yield() behaviour, but also modifies how in-kernel yield() calls behave for threaded processes. That is probably not right. So here is a diff that

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Alexandre Ratchov
On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > > > > This doesn't only change the sched_yield() behaviour, but also > > modifies how in-kernel yield() calls behave for threaded processes. > > That is probably not right. > > So here is a diff that keeps yield() the same and adds

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Alexandre Ratchov
On Wed, Mar 23, 2016 at 06:18:59PM -0400, Ted Unangst wrote: > Mark Kettenis wrote: > > So here is a diff that keeps yield() the same and adds the code in the > > sched_yield(2) implementation instead. It also changes the logic that > > picks the priority to walk the complete threads listand pick

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Ted Unangst
Mark Kettenis wrote: > So here is a diff that keeps yield() the same and adds the code in the > sched_yield(2) implementation instead. It also changes the logic that > picks the priority to walk the complete threads listand pick the > highest priotity of all the threads. That should be enough to

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Martin Pieuchot
On 23/03/16(Wed) 21:35, Mark Kettenis wrote: > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > > From: Mark Kettenis > > > > > Date: Sat, 19 Mar 2016 13:53:07 +0100 > > > From: Martin Pieuchot > > > > > > Applications using multiple threads often call

Re: Scheduler hack for multi-threaded processes

2016-03-23 Thread Mark Kettenis
> Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > From: Mark Kettenis > > > Date: Sat, 19 Mar 2016 13:53:07 +0100 > > From: Martin Pieuchot > > > > Applications using multiple threads often call sched_yield(2) to > > indicate that one of the threads

Re: sdhc: don't always compile the pci attachment driver

2016-03-23 Thread Mark Kettenis
> Date: Fri, 4 Mar 2016 22:32:19 +0100 > From: Patrick Wildt > > Hi, > > if you attach sdhc, you automatically compile the pci attachment driver, > even if there's no "sdhc* at pci?" in the config. This might fail on > architectures that don't have pci compiled in. > > If

use fast lookup in in6_pcbconnect()

2016-03-23 Thread Vincent Gross
The current use of in_pcblookup() in in6_pcbconnect() is suboptimal : all of the addresses and ports are defined, we are only interested in exact matches, and its v4 cousin in_pcbconnect() already uses in_pcbhashlookup(). Ok ? Index: sys/netinet6/in6_pcb.c

uvm: remove unused(?) amap_extend

2016-03-23 Thread Stefan Kempf
amap_extend is called when merging two adjacent areas of virtual address space. However, merging is done only for kernel virtual address space. It's not done for user space: uvm/uvm_map.c:1359 /* * Try to merge entry. * * Userland allocations are kept separated

Re: Fix overflow check in sys/kern/kern_time.c

2016-03-23 Thread Todd C. Miller
On Wed, 23 Mar 2016 10:58:42 -0400, Michael McConville wrote: > I'm not sure whether avoiding incrementing here is an ideal move, but > this diff definitely works toward a local optimum. Namely, that error > check is technically meaningless because signed overflow is undefined. > > ok? Or would

Re: Fix overflow check in sys/kern/kern_time.c

2016-03-23 Thread Michael McConville
Mark Kettenis wrote: > > I'm not sure whether avoiding incrementing here is an ideal move, but > > this diff definitely works toward a local optimum. Namely, that error > > check is technically meaningless because signed overflow is undefined. > > Within the kernel, signed overflow actually is

Re: Fix overflow check in sys/kern/kern_time.c

2016-03-23 Thread Mark Kettenis
> Date: Wed, 23 Mar 2016 10:58:42 -0400 > From: Michael McConville > > I'm not sure whether avoiding incrementing here is an ideal move, but > this diff definitely works toward a local optimum. Namely, that error > check is technically meaningless because signed overflow is

Fix overflow check in sys/kern/kern_time.c

2016-03-23 Thread Michael McConville
I'm not sure whether avoiding incrementing here is an ideal move, but this diff definitely works toward a local optimum. Namely, that error check is technically meaningless because signed overflow is undefined. ok? Or would people prefer a solution that's robust to changing *curpps's type?

Re: Proxy ARP and published entry

2016-03-23 Thread Alexander Bluhm
On Mon, Mar 21, 2016 at 02:29:46PM +0100, Martin Pieuchot wrote: > When the caller of arplookup() asked for a proxy'd ARP entry, make > sure the entry returned by rtalloc(9) is indeed "published". > > This is currently always true for ARP entries added with arp(8) but > it is not the case if you

Re: www.openbsd.org/cgi-bin/man.cgi

2016-03-23 Thread lists
Wed, 23 Mar 2016 10:07:10 + skin...@britvault.co.uk (Craig Skinner) > On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote: > > > > A few years back, Ingo moved it to the new mandoc based man.cgi, and > > now we've actually moved this to a dedicated place - "man.openbsd.org" > > Superb. What's next?

Re: www.openbsd.org/cgi-bin/man.cgi

2016-03-23 Thread Craig Skinner
On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote: > > A few years back, Ingo moved it to the new mandoc based man.cgi, and > now we've actually moved this to a dedicated place - "man.openbsd.org" > Superb. What's next? $ ssh gu...@man.openbsd.org Welcome guest user to OpenBSD's online manual

multi-pool malloc wip diff

2016-03-23 Thread Otto Moerbeek
Hi, first diff that seems to work. Tested on amd64 and compile tested on sparc64. It is alo available at http://www.drijf.net/openbsd/malloc Form the README: The diff should be applied while in /usr/src/lib, it will patch both librthreads as as well as libc. THIS IS WORK IN PROGRESS. It

faq6.html: Fix typo uaw -> use

2016-03-23 Thread Juuso Lapinlampi
This typo was introduced in revision 1.346. Index: www/faq/faq6.html === RCS file: /cvs/www/faq/faq6.html,v retrieving revision 1.357 diff -u -r1.357 faq6.html --- www/faq/faq6.html 22 Mar 2016 10:54:47 - 1.357 +++

tcpdump crashes in print-cdp.c

2016-03-23 Thread Can Erkin Acar
Here is a new version of the diff that fixes the CDP printer in tcpdump. (https://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/tcpdump-crashes/) With this change the code does not access outside the packet anymore but it would be nice if it could be tested on a network with real CDP (Cisco

Re: www.openbsd.org/cgi-bin/man.cgi

2016-03-23 Thread Ingo Schwarze
Hi, Bob Beck wrote on Tue, Mar 22, 2016 at 10:49:37PM -0600: > This has been our constant friend for many many years. I babied some > truly horrible perl that did this, along with some nasty things to > extract the old man pages for many years. > > It is now no more. > > A few years back,