Re: CVS commit: src/sys/arch

2013-06-24 Thread YAMAMOTO Takashi
hi, > Because I don't want to change resulting binaries (*.o) for now. I > think I'll "switch" these when cleaned up and merged and moved to > sys/arch/x86. How do you think? fine for me as far as this inclusion is temporary. YAMAMOTO Takashi > > On Tue, Jun 25, 2013 at 12:17 PM, YAMAMOTO Ta

Re: CVS commit: src/sys/arch

2013-06-24 Thread Masao Uebayashi
Because I don't want to change resulting binaries (*.o) for now. I think I'll "switch" these when cleaned up and merged and moved to sys/arch/x86. How do you think? On Tue, Jun 25, 2013 at 12:17 PM, YAMAMOTO Takashi wrote: > hi, > > why do you need to make *.S include another *.S > rather than

Re: CVS commit: src/sys/arch

2013-06-24 Thread YAMAMOTO Takashi
hi, why do you need to make *.S include another *.S rather than tweaking makefile? YAMAMOTO Takashi > Module Name: src > Committed By: uebayasi > Date: Tue Jun 25 00:27:22 UTC 2013 > > Modified Files: > src/sys/arch/amd64/amd64: vector.S > src/sys/arch/i386/i386: vector.S >

Re: CVS commit: src

2013-06-24 Thread Taylor R Campbell
Date: Mon, 24 Jun 2013 17:22:34 +0200 From: Thomas Klausner I tried 'make distribution' twice now, second time after completely removing tools and obj dirs, but it doesn't finish for me. I see: --- dependall-client --- /lib/libcrypt.so.1: undefined reference to `__explicit_bzero

Re: CVS commit: src

2013-06-24 Thread Taylor R Campbell
Date: Mon, 24 Jun 2013 09:52:14 +0200 From: Alan Barrett I think that the names explicit_memzero() and consttime_memeq() are fine, but I'd expect consttime_memeq() have the opposite polarity from consttime_bcmp(), because it should be answering the question "are they equal?"

Re: CVS commit: src

2013-06-24 Thread Thomas Klausner
ode 1 I can't say I understand this. /usr/src has no references to this left. I basically do: machine=amd64 UPDATE_FLAG= today=20130624 sh build.sh -V DBG="-O2 -g" -V MKLLVM=yes -x -j 16 $UPDATE_FLAG -T /archive/build/tools.clang-build-only -m $machine -O /usr/obj/src.$machine -D /archive/build/$machine.clang-build-only.$today distribution and my /usr/obj/src.amd64 was empty. Ideas? Thomas

Re: CVS commit: src/lib/libc/string

2013-06-24 Thread Christos Zoulas
On Jun 24, 4:35am, riastr...@netbsd.org (Taylor R Campbell) wrote: -- Subject: Re: CVS commit: src/lib/libc/string | Oops, that was silly of me -- the libc symbols actually have a double- | underscore prefix, presumably meaning `these are internal; do not | use'. Should I move the man pages to s

Re: CVS commit: src/lib/libc/string

2013-06-24 Thread Christos Zoulas
On Jun 24, 3:54am, riastr...@netbsd.org (Taylor R Campbell) wrote: -- Subject: Re: CVS commit: src/lib/libc/string |Date: Mon, 24 Jun 2013 01:36:29 + (UTC) |From: chris...@astron.com (Christos Zoulas) | |I've objected many times railroading those in and casting the into stone |

Re: CVS commit: src/sys/arch/sparc64

2013-06-24 Thread Martin Husemann
On Mon, Jun 24, 2013 at 06:16:14PM +0900, Takeshi Nakayama wrote: > Yes, I understand it. I just forgot to write "for now". No problem - we need to review all MD code at that point anyway. Martin

Re: CVS commit: src/sys/arch/sparc64

2013-06-24 Thread Takeshi Nakayama
>>> Martin Husemann wrote > On Mon, Jun 24, 2013 at 10:41:11AM +0900, Takeshi Nakayama wrote: > > It seems sparc64's MD codes don't treat about kpreempt, so I didn't > > care about kpreempt. > > Yet - but this will change. > > Martin Yes, I understand it. I just forgot to write "for now". --

Re: CVS commit: src/lib/libc/string

2013-06-24 Thread Alan Barrett
On Mon, 24 Jun 2013, Taylor R Campbell wrote: Discuss on tech-userlevel? Yes please. --apb (Alan Barrett)

Re: CVS commit: src

2013-06-24 Thread Alan Barrett
On Sun, 23 Jun 2013, Taylor R Campbell wrote: From: chris...@astron.com (Christos Zoulas) We should not be creating new interfaces based on obsolete ones. I'd rather we have consttime_memcmp() and explicit_memset(). I don't care if we rename them to consttime_memeq and explicit_memzero in