libc/sparc64 ABI cleanup

2016-05-07 Thread Philip Guenther
Currently, the soft-float bits in libc on sparc64 export not just the sparc ABI symbols _Q_* and _Qp_*, but also the internal implementation bits, __fpu_* AFAICT, the __fpu_* names are not required by our tool chain; in contrast, calls to the _Q* names are generated by gcc. Diff below cleans

Re: [patch] memory leak in vi

2016-05-07 Thread Todd C. Miller
On Sat, 07 May 2016 15:10:24 +0200, Martijn van Duren wrote: > There's a memory leak in vi in the REALLOC{,ARRAY} macro. > This patch should fix the leak. A similar diff is already > present in FreeBSD's vi. OK millert@ - todd

Re: xclock patch

2016-05-07 Thread Theo de Raadt
> > So I don't understand why pledge is being added here. > > Because you suggested it back in november... Of course I suggested it: I believe I said it would be nice if the simplest of X programs were investigated. But everywhere else pledge was inserted, that requires (a) full understanding of

Re: xclock patch

2016-05-07 Thread Matthieu Herrb
On Sat, May 07, 2016 at 07:15:00AM -0600, Theo de Raadt wrote: > > On Sat, May 07, 2016 at 06:48:58AM -0500, Edgar Pettijohn wrote: > > > > > > > > else, if it isn't in xclock code, it could be a open(2) call in some > > > > X11R6 library. > > > > > > > I looked all I found was access() which if

Re: rtadvd.conf.5: document route preference flags

2016-05-07 Thread Jeremie Courreges-Anglas
Martin Pieuchot writes: > On 06/05/16(Fri) 21:42, Jeremie Courreges-Anglas wrote: >> >> Also motivated by http://marc.info/?l=openbsd-misc&m=146239072929264&w=2 >> >> RFC4191 defines route preference flags not only in Route Information >> options, but also in Router Advertisement messages. Let

Fwd: CVS: cvs.openbsd.org: src

2016-05-07 Thread Philip Guenther
For those who don't following source-changes but build -current from source... I just committed a major ABI change; threaded binaries from before late-March will no longer work and you need to follow the instructions I just committed to the FAQ's "following -current" page! This is probably a good

Re: ld patch that greatly speeds up linking large programs with debug symbols

2016-05-07 Thread Stefan Kempf
Aaron Miller wrote: > Hi All, > > I was experiencing ~8 minute linking times for a large C++ application > I have been working on when running -current on amd64. It turns out > that the decade-old version of ld in the OpenBSD source tree has a bug > that causes quadratic complexity for some linkin

Re: xclock patch

2016-05-07 Thread Edgar Pettijohn
Sent from my iPhone > On May 7, 2016, at 8:03 AM, Sebastien Marie wrote: > > On Sat, May 07, 2016 at 06:48:58AM -0500, Edgar Pettijohn wrote: >>> >>> else, if it isn't in xclock code, it could be a open(2) call in some >>> X11R6 library. >> I looked all I found was access() which if I'm readi

Re: ifconfig(8): Do not print MPSAFE

2016-05-07 Thread Mark Kettenis
> Date: Sat, 7 May 2016 18:44:34 +0200 > From: Peter Hessler > > SINCE THIS IS UNDER HEAVY DEVELOPMENT: as a user, I want to know if my > interface is marked as MP safe or not. > > I don't care if this is done in dmesg, or in ifconfig. > > once it stabilizes, I'm happy for the notice to go away

Re: ifconfig(8): Do not print MPSAFE

2016-05-07 Thread Theo de Raadt
> SINCE THIS IS UNDER HEAVY DEVELOPMENT: as a user, I want to know if my > interface is marked as MP safe or not. > > I don't care if this is done in dmesg, or in ifconfig. > > once it stabilizes, I'm happy for the notice to go away. Disagree strongly. That mindset would drive us towards puttin

Re: ifconfig(8): Do not print MPSAFE

2016-05-07 Thread Peter Hessler
SINCE THIS IS UNDER HEAVY DEVELOPMENT: as a user, I want to know if my interface is marked as MP safe or not. I don't care if this is done in dmesg, or in ifconfig. once it stabilizes, I'm happy for the notice to go away. On 2016 May 07 (Sat) at 16:56:02 +0200 (+0200), Martin Pieuchot wrote: :I

Re: ifconfig(8): Do not print MPSAFE

2016-05-07 Thread Mark Kettenis
> Date: Sat, 7 May 2016 16:56:02 +0200 > From: Martin Pieuchot > > IFXF_MPSAFE is a hint for the network stack. When it is set, the kernel > knows that it doesn't need to grab the KERNEL_LOCK() to call the start() > routine of an interface. > > Exposing this flag to users in ifconfig(8) does no

ifconfig(8): Do not print MPSAFE

2016-05-07 Thread Martin Pieuchot
IFXF_MPSAFE is a hint for the network stack. When it is set, the kernel knows that it doesn't need to grab the KERNEL_LOCK() to call the start() routine of an interface. Exposing this flag to users in ifconfig(8) does not make sense. This is a side effect of having re-used the IFXF_TXREADY bit.

Re: xclock patch

2016-05-07 Thread Theo de Raadt
> On Sat, May 07, 2016 at 06:48:58AM -0500, Edgar Pettijohn wrote: > > > > > > else, if it isn't in xclock code, it could be a open(2) call in some > > > X11R6 library. > > > > > I looked all I found was access() which if I'm reading pledge correctly it > > doesn't need pledge. Is that right? >

[patch] memory leak in vi

2016-05-07 Thread Martijn van Duren
Hello tech@, There's a memory leak in vi in the REALLOC{,ARRAY} macro. This patch should fix the leak. A similar diff is already present in FreeBSD's vi. OK? martijn@ Index: common/mem.h === RCS file: /cvs/src/usr.bin/vi/common/mem

Re: xclock patch

2016-05-07 Thread Sebastien Marie
On Sat, May 07, 2016 at 06:48:58AM -0500, Edgar Pettijohn wrote: > > > > else, if it isn't in xclock code, it could be a open(2) call in some > > X11R6 library. > > > I looked all I found was access() which if I'm reading pledge correctly it > doesn't need pledge. Is that right? > now, I am un

Re: xclock patch

2016-05-07 Thread Sebastien Marie
On Sat, May 07, 2016 at 06:48:58AM -0500, Edgar Pettijohn wrote: > > > > else, if it isn't in xclock code, it could be a open(2) call in some > > X11R6 library. > > > I looked all I found was access() which if I'm reading pledge correctly it > doesn't need pledge. Is that right? > What I mean

Re: gif tunnel and IPv6 ND

2016-05-07 Thread Martin Pieuchot
On 27/04/16(Wed) 18:13, Martin Pieuchot wrote: > gif(4) is the only p2p interface for which the kernel does some kind of > link-layer address resolution when it comes to IPv6 & ND. > > I don't believe this is necessary because we do not install any cloning > route on p2p interfaces. However the r

Re: xclock patch

2016-05-07 Thread Edgar Pettijohn
Sent from my iPhone > On May 6, 2016, at 11:49 PM, Sebastien Marie wrote: > > On Fri, May 06, 2016 at 01:29:11PM -0500, Edgar Pettijohn wrote: >>> On May 6, 2016, at 12:13 PM, Matthieu Herrb wrote: >>> On Tue, May 03, 2016 at 11:40:31AM -0500, Edgar Pettijohn wrote: I'll look at it

Re: ip6_input: Double check for mapped v4 addresses

2016-05-07 Thread Martin Pieuchot
On 06/05/16(Fri) 14:22, Stuart Henderson wrote: > On 2016/05/06 15:05, Martin Pieuchot wrote: > > This look like a bad merge from 2000s. This check is present twice in > > ip6_input(), so let's remove the late one, ok? > > > > Index: netinet6/ip6_input.c > > ==

Re: rtadvd.conf.5: document route preference flags

2016-05-07 Thread Martin Pieuchot
On 06/05/16(Fri) 21:42, Jeremie Courreges-Anglas wrote: > > Also motivated by http://marc.info/?l=openbsd-misc&m=146239072929264&w=2 > > RFC4191 defines route preference flags not only in Route Information > options, but also in Router Advertisement messages. Let's try to make > this clear. Als

Re: dhclient: use /dev/bpf

2016-05-07 Thread Martin Natano
On Fri, May 06, 2016 at 07:17:50PM +0100, Stuart Henderson wrote: > > Personally, my preferred course of action would be to switch to > looking for /dev/bpf0 for now (bpf0 only: *not* revert to the old > loop, that's not necessary), and then switch to /dev/bpf > immediately after 6.0 is released.