update if_opackets with if_obytes in if_enqueue

basically this unifies the meaning of and operations on the output packet andbyte counters. the byte counter currently means how many bytes were successfully queued in software for transmission. traditionally the if_opackets counter generally means how many packets were successfully queued on the

Vos pièces auto en 2 minutes chrono ? Avec AutoRecup, c'est facile...

? ? ? ? 950 casses auto ? votre service... www.AutoRecup.com vos pi?ces auto en 2 minutes chrono AutoRecup envoie votre demande ? 950 recycleurs auto Ceux qui ont la pi?ce vous envoient une offre de prix par mail Choisissez l'offre qui vous plait... :-) Gratuit et sans aucune

Re: llvm: install clang as cc,c++,cpp and lld as ld

On Sun, Jan 22, 2017 at 01:42:19PM +1000, Patrick Wildt wrote: > Hi, > > in architectures which use clang by default we should provide clang as > cc, c++ and cpp as well. Also lld should be called ld. > > ok? > > Patrick > Of course it needs to be guarded with COMPILER_VERSION on lld as

llvm: install clang as cc,c++,cpp and lld as ld

Hi, in architectures which use clang by default we should provide clang as cc, c++ and cpp as well. Also lld should be called ld. ok? Patrick diff --git a/gnu/usr.bin/clang/clang/Makefile b/gnu/usr.bin/clang/clang/Makefile index b16aaa5e67c..104f7c593f1 100644 ---

Re: fix BOOTSTRAP_CLANG in mk.conf build

> Date: Sun, 22 Jan 2017 13:06:54 +1100 > From: Jonathan Gray > > gnu/usr.bin/clang/Makefile.inc sets CC based on BOOTSTRAP_CLANG, most > local llvm Makefiles include bsd.own.mk which picks up mk.conf > definitions, these few don't which breaks the build when BOOTSTRAP_CLANG > is

Re: fix BOOTSTRAP_CLANG in mk.conf build

On Sun, Jan 22, 2017 at 01:06:54PM +1100, Jonathan Gray wrote: > gnu/usr.bin/clang/Makefile.inc sets CC based on BOOTSTRAP_CLANG, most > local llvm Makefiles include bsd.own.mk which picks up mk.conf > definitions, these few don't which breaks the build when BOOTSTRAP_CLANG > is set in mk.conf

Re: llvm: add infrastructure to build lld

> Date: Sun, 22 Jan 2017 11:47:46 +1000 > From: Patrick Wildt > > Hi, > > for arm64 our goal is to use lld. Even though we really need lld 4.0, > which is not yet released, it is already a good start to have lld 3.9.1 > make infrastructure available. This diff adds the

Re: Linking userland with lld

On Sat, Jan 21, 2017 at 10:58:59AM +0100, Mark Kettenis wrote: > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our > ancient binutils we don't notice this, because we link against libtls, > which as a DT_NEEDED

fix BOOTSTRAP_CLANG in mk.conf build

gnu/usr.bin/clang/Makefile.inc sets CC based on BOOTSTRAP_CLANG, most local llvm Makefiles include bsd.own.mk which picks up mk.conf definitions, these few don't which breaks the build when BOOTSTRAP_CLANG is set in mk.conf instead of the environment. Index: clang/Makefile

Re: userspace doesn't need to set sa_len, sun_len, etc

On Sun, Jan 22, 2017 at 07:07:28AM +1000, Philip Guenther wrote: > On Sun, 22 Jan 2017, Martin Pieuchot wrote: > > On 21/01/17(Sat) 20:40, Philip Guenther wrote: > > > > > > This is your periodic reminder that it's pointless for userspace to set > > > the {sun,sin,sin6,etc}_len field in

Re: userspace doesn't need to set sa_len, sun_len, etc

On Sun, 22 Jan 2017, Martin Pieuchot wrote: > On 21/01/17(Sat) 20:40, Philip Guenther wrote: > > > > This is your periodic reminder that it's pointless for userspace to set > > the {sun,sin,sin6,etc}_len field in sockaddrs being passed to the POSIX > > APIs. An application can use it

Re: userspace doesn't need to set sa_len, sun_len, etc

On 21/01/17(Sat) 20:40, Philip Guenther wrote: > > This is your periodic reminder that it's pointless for userspace to set > the {sun,sin,sin6,etc}_len field in sockaddrs being passed to the POSIX > APIs. An application can use it internally for its own purposes, but the > kernel always

Re: userspace doesn't need to set sa_len, sun_len, etc

Philip Guenther(guent...@gmail.com) on 2017.01.21 20:40:53 +1000: > > This is your periodic reminder that it's pointless for userspace to set > the {sun,sin,sin6,etc}_len field in sockaddrs being passed to the POSIX > APIs. An application can use it internally for its own purposes, but the >

Re: Linking userland with lld

> The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3 > binutils. Mostly works, but it triggers an issue in building ldapd > and ldapctl. > > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our >

Re: iwm: fix a timeout race

On Sat, Jan 21, 2017 at 08:07:53PM +1300, Richard Procter wrote: > Hi, > > On 18/01/2017, Stefan Sperling wrote: > > I managed to trigger the following uvm fault by continously switching an > > iwm(4) client between two APs on different channels, i.e. a loop that runs: > >

userspace doesn't need to set sa_len, sun_len, etc

This is your periodic reminder that it's pointless for userspace to set the {sun,sin,sin6,etc}_len field in sockaddrs being passed to the POSIX APIs. An application can use it internally for its own purposes, but the kernel always overwrites the value when passed in. There are more of these

Re: Linking userland with lld

I stole your diff yesterday, when I built a static snapshot for fun. > The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3 > binutils. Mostly works, but it triggers an issue in building ldapd > and ldapctl. > > The problem here is that the code uses the SHA1 functions in >

Linking userland with lld

The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3 binutils. Mostly works, but it triggers an issue in building ldapd and ldapctl. The problem here is that the code uses the SHA1 functions in libcrypto, but doesn't explicitly link against that library. With our ancient binutils we

Re: sunxi: clock for PIO

> Date: Sat, 21 Jan 2017 17:38:30 +1000 > From: Patrick Wildt > > Hi, > > this diff adds the clock for the Allwinner A64 PIO. > > ok? ok kettenis@ > diff --git a/sys/arch/armv7/sunxi/sxiccmu_clocks.h > b/sys/arch/armv7/sunxi/sxiccmu_clocks.h > index