svn commit: r228893 - head/sys/dev/ath/ath_hal/ar5416
Author: adrian Date: Mon Dec 26 08:21:29 2011 New Revision: 228893 URL: http://svn.freebsd.org/changeset/base/228893 Log: AR5416 has 14 GPIO pins, from 0->13. Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c == --- head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c Mon Dec 26 07:48:29 2011(r228892) +++ head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c Mon Dec 26 08:21:29 2011(r228893) @@ -865,7 +865,7 @@ ar5416FillCapabilityInfo(struct ath_hal ; pCap->halFastCCSupport = AH_TRUE; - pCap->halNumGpioPins = 6; + pCap->halNumGpioPins = 14; pCap->halWowSupport = AH_FALSE; pCap->halWowMatchPatternExact = AH_FALSE; pCap->halBtCoexSupport = AH_FALSE; /* XXX need support */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228894 - vendor/netcat/dist
Author: delphij
Date: Mon Dec 26 08:59:17 2011
New Revision: 228894
URL: http://svn.freebsd.org/changeset/base/228894
Log:
Import nc from OpenBSD 5.0.
Modified:
vendor/netcat/dist/netcat.c
Modified: vendor/netcat/dist/netcat.c
==
--- vendor/netcat/dist/netcat.c Mon Dec 26 08:21:29 2011(r228893)
+++ vendor/netcat/dist/netcat.c Mon Dec 26 08:59:17 2011(r228894)
@@ -1,4 +1,4 @@
-/* $OpenBSD: netcat.c,v 1.100 2011/01/09 22:16:46 jeremy Exp $ */
+/* $OpenBSD: netcat.c,v 1.101 2011/06/21 17:31:07 mikeb Exp $ */
/*
* Copyright (c) 2001 Eric Jackson
*
@@ -552,7 +552,7 @@ remote_connect(const char *host, const c
continue;
if (rtableid) {
- if (setsockopt(s, IPPROTO_IP, SO_RTABLE, &rtableid,
+ if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
sizeof(rtableid)) == -1)
err(1, "setsockopt SO_RTABLE");
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228895 - vendor/netcat/5.0
Author: delphij Date: Mon Dec 26 09:03:28 2011 New Revision: 228895 URL: http://svn.freebsd.org/changeset/base/228895 Log: Tag nc from OpenBSD 5.0. Added: vendor/netcat/5.0/ - copied from r228894, vendor/netcat/dist/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228896 - head/contrib/netcat
Author: delphij Date: Mon Dec 26 09:07:08 2011 New Revision: 228896 URL: http://svn.freebsd.org/changeset/base/228896 Log: Merge from OpenBSD 5.0 (this is a dummy change, the vendor change does not apply to us). Modified: head/contrib/netcat/netcat.c Directory Properties: head/contrib/netcat/ (props changed) Modified: head/contrib/netcat/netcat.c == --- head/contrib/netcat/netcat.cMon Dec 26 09:03:28 2011 (r228895) +++ head/contrib/netcat/netcat.cMon Dec 26 09:07:08 2011 (r228896) @@ -1,4 +1,4 @@ -/* $OpenBSD: netcat.c,v 1.100 2011/01/09 22:16:46 jeremy Exp $ */ +/* $OpenBSD: netcat.c,v 1.101 2011/06/21 17:31:07 mikeb Exp $ */ /* * Copyright (c) 2001 Eric Jackson * ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228896 - head/contrib/netcat
On 12/26/2011 01:07, Xin LI wrote: > Author: delphij > Date: Mon Dec 26 09:07:08 2011 > New Revision: 228896 > URL: http://svn.freebsd.org/changeset/base/228896 > > Log: > Merge from OpenBSD 5.0 (this is a dummy change, the vendor change does not > apply to us). When I'm importing stat(1) stuff from Net/OpenBSD I don't do this. I will however comment in the commit log for the next substantive change, "Skipped update N.NN because the change was not relevant to us," or words to that effect. I'm not suggesting that my way of doing this is perfect, or cannot be improved. I would suggest however that this change was needless churn. hth, Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: > On 12/24/2011 04:16, Marius Strobl wrote: > > On FreeBSD just use the MD5 implementation of libmd rather than that of > > libcrypto so we don't need to relinquish csup when world is built without > > OpenSSL. > > Did you benchmark this at all? I agree that keeping csup available > absent openssl is a good goal, but csup is a prototypical "tool that > does the same thing many thousands of times" so even tiny regressions > could add up to a large cost in wall clock time. Well, in a real world test updating the same base on an amd64 machine connected to the Internet via Fast Ethernet from a national mirror with csup once linked against libcrypto and once against libmd and also with CVSup the csup linked against libmd actually was fasted with 29:51.37, followed by CVSup with 32:07.52 and csup linked against libcrypto with 34:49.88. This was with the libmd run done after the libcrypto run so in theory the former might even have picked up some more deltas than the latter. On the other hand the MD5 implementation of libmd is known to be 18-20% slower at least on x86 that that of libcrypto (probably due to its assembler implementation). I only can reliably reproduce that when checksumming files starting in the several hundreds MB range, at least when they are on disk. So in order to also see that slowdown with csup linked against libmd I guess you'd at least need some artificial setup with both server and client being on the LAN and having the repositories on memory backed disks, if at all possible. Using the libmd MD5 implementation for csup doesn't seem to have a real world impact though. > > If the openssl version is faster, then conditionalizing where to get md5 > is probably the right answer. > If we really cared about the MD5 performance of applications linked against libmd (including md5(1)), we should just optimize that MD5 implementation rather than working around it. Also for csup, fixing the problem that is causing it to fetch whole files over and over again likely would improve its performance way more than using a different MD5 implementation could do. Marius ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228897 - head/sys/sys
Author: ed Date: Mon Dec 26 10:58:21 2011 New Revision: 228897 URL: http://svn.freebsd.org/changeset/base/228897 Log: The standard is now called C11 -- C12. While there, compare against the proper __STDC_VERSION value. Modified: head/sys/sys/cdefs.h Modified: head/sys/sys/cdefs.h == --- head/sys/sys/cdefs.hMon Dec 26 09:07:08 2011(r228896) +++ head/sys/sys/cdefs.hMon Dec 26 10:58:21 2011(r228897) @@ -223,7 +223,7 @@ #endif /* - * Keywords added in C1X. + * Keywords added in C11. */ #if defined(__cplusplus) && __cplusplus >= 201103L #define_Alignas(e) alignas(e) @@ -231,7 +231,7 @@ #define_Noreturn [[noreturn]] #define_Static_assert(e, s)static_assert(e, s) #define_Thread_local thread_local -#elif defined(__STDC_VERSION__) && __STDC_VERSION__ > 201000L +#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L /* Do nothing. They are language keywords. */ #else /* Not supported. Implement them using our versions. */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228874 - head/sys/dev/hwpmc
On Dec 26, 2011, at 1:23 AM, Doug Barton wrote: On 12/25/2011 06:29, Bjoern A. Zeeb wrote: Author: bz Date: Sun Dec 25 14:29:36 2011 New Revision: 228874 URL: http://svn.freebsd.org/changeset/base/228874 Log: Quite the tinderbox for the holidays. Remove the assert[1]. Shouldn't "Why it's Ok to remove the assert" be part of this commit log? When I suggested the removal, I didn't see it as necessary, and was just looking to quiet the build for now while I look closer. Right now, that code is never called, as it's only used when configured for sampling, and that code was originally just a copy from the hwpmc_amd driver. I will be finishing the sampling code in the new year. - Justin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228898 - head/sbin/dumpfs
Author: brueffer
Date: Mon Dec 26 16:47:45 2011
New Revision: 228898
URL: http://svn.freebsd.org/changeset/base/228898
Log:
Add missing -l flag to usage().
PR: 163629
Submitted by: olgeni
MFC after:1 week
Modified:
head/sbin/dumpfs/dumpfs.c
Modified: head/sbin/dumpfs/dumpfs.c
==
--- head/sbin/dumpfs/dumpfs.c Mon Dec 26 10:58:21 2011(r228897)
+++ head/sbin/dumpfs/dumpfs.c Mon Dec 26 16:47:45 2011(r228898)
@@ -499,6 +499,6 @@ ufserr(const char *name)
static void
usage(void)
{
- (void)fprintf(stderr, "usage: dumpfs [-fm] filesys | device\n");
+ (void)fprintf(stderr, "usage: dumpfs [-flm] filesys | device\n");
exit(1);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228900 - head/sys/sys
Author: ed Date: Mon Dec 26 18:49:56 2011 New Revision: 228900 URL: http://svn.freebsd.org/changeset/base/228900 Log: Add cdefs-magic to add optional C11 bits to headers. Modified: head/sys/sys/cdefs.h Modified: head/sys/sys/cdefs.h == --- head/sys/sys/cdefs.hMon Dec 26 18:12:27 2011(r228899) +++ head/sys/sys/cdefs.hMon Dec 26 18:49:56 2011(r228900) @@ -609,11 +609,16 @@ #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 #define__ISO_C_VISIBLE 1999 +#elif defined(_C11_SOURCE) /* Localism to specify strict C11 env. */ +#define__POSIX_VISIBLE 0 +#define__XSI_VISIBLE 0 +#define__BSD_VISIBLE 0 +#define__ISO_C_VISIBLE 2011 #else /* Default environment: show everything. */ #define__POSIX_VISIBLE 200809 #define__XSI_VISIBLE 700 #define__BSD_VISIBLE 1 -#define__ISO_C_VISIBLE 1999 +#define__ISO_C_VISIBLE 2011 #endif #endif ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228901 - head/include
Author: ed Date: Mon Dec 26 18:55:37 2011 New Revision: 228901 URL: http://svn.freebsd.org/changeset/base/228901 Log: Improve C11 bits in : - Add missing semicolon to quick_exit(), - Remove `func' parameter name from at_quick_exit(), - Fix indentation. - Compare against 2011 value. Modified: head/include/stdlib.h Modified: head/include/stdlib.h == --- head/include/stdlib.h Mon Dec 26 18:49:56 2011(r228900) +++ head/include/stdlib.h Mon Dec 26 18:55:37 2011(r228901) @@ -151,11 +151,11 @@ _Noreturn void _Exit(int); /* * If we're in a mode greater than C99, expose C1x functions. */ -#if __ISO_C_VISIBLE > 1999 -_Noreturn void quick_exit(int) -int -at_quick_exit(void (*func)(void)); -#endif /* __ISO_C_VISIBLE > 1999 */ +#if __ISO_C_VISIBLE >= 2011 +_Noreturn void + quick_exit(int); +intat_quick_exit(void (*)(void)); +#endif /* __ISO_C_VISIBLE >= 2011 */ /* * Extensions made by POSIX relative to C. We don't know yet which edition * of POSIX made these extensions, so assume they've always been there until ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228902 - head/include
Author: ed Date: Mon Dec 26 18:57:59 2011 New Revision: 228902 URL: http://svn.freebsd.org/changeset/base/228902 Log: As per C11, add static_assert() to . Modified: head/include/assert.h Modified: head/include/assert.h == --- head/include/assert.h Mon Dec 26 18:55:37 2011(r228901) +++ head/include/assert.h Mon Dec 26 18:57:59 2011(r228902) @@ -57,7 +57,13 @@ #ifndef _ASSERT_H_ #define _ASSERT_H_ + +#if __ISO_C_VISIBLE >= 2011 && (!defined(__cplusplus) || __cplusplus < 201103L) +#definestatic_assert _Static_assert +#endif + __BEGIN_DECLS void __assert(const char *, const char *, int, const char *) __dead2; __END_DECLS + #endif /* !_ASSERT_H_ */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228903 - head/tools/tools/ath
Author: adrian Date: Mon Dec 26 19:41:46 2011 New Revision: 228903 URL: http://svn.freebsd.org/changeset/base/228903 Log: Oops, my bad. Fix a broken thing I introduced earlier. Modified: head/tools/tools/ath/Makefile Modified: head/tools/tools/ath/Makefile == --- head/tools/tools/ath/Makefile Mon Dec 26 18:57:59 2011 (r228902) +++ head/tools/tools/ath/Makefile Mon Dec 26 19:41:46 2011 (r228903) @@ -1,7 +1,7 @@ # $FreeBSD$ SUBDIR=arcode athdebug athdecode athkey athpoke athprom athrd athregs -SUBDIR+= athstats ath_prom_read ath_radar +SUBDIR+= athstats ath_prom_read athradar SUBDIR+= ath_ee_v14_print ath_ee_v4k_print ath_ee_9287_print .include ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228874 - head/sys/dev/hwpmc
On 12/26/2011 04:50, Justin Hibbits wrote: > On Dec 26, 2011, at 1:23 AM, Doug Barton wrote: > >> On 12/25/2011 06:29, Bjoern A. Zeeb wrote: >>> Author: bz >>> Date: Sun Dec 25 14:29:36 2011 >>> New Revision: 228874 >>> URL: http://svn.freebsd.org/changeset/base/228874 >>> >>> Log: >>> Quite the tinderbox for the holidays. Remove the assert[1]. >> >> Shouldn't "Why it's Ok to remove the assert" be part of this commit log? > > When I suggested the removal, I didn't see it as necessary, and was just > looking to quiet the build for now while I look closer. Right now, that > code is never called, as it's only used when configured for sampling, > and that code was originally just a copy from the hwpmc_amd driver. I > will be finishing the sampling code in the new year. Thank you for the explanation. -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On 12/26/2011 02:28, Marius Strobl wrote: > On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: >> On 12/24/2011 04:16, Marius Strobl wrote: >>> On FreeBSD just use the MD5 implementation of libmd rather than that of >>> libcrypto so we don't need to relinquish csup when world is built without >>> OpenSSL. >> >> Did you benchmark this at all? I agree that keeping csup available >> absent openssl is a good goal, but csup is a prototypical "tool that >> does the same thing many thousands of times" so even tiny regressions >> could add up to a large cost in wall clock time. > > Well, in a real world test updating the same base on an amd64 machine > connected to the Internet Adding a network connection to the test is almost certainly going to obscure the results beyond utility. The appropriate way to test this would be to create a binary out of the md5 routine in csup, and link it alternately with libcrypto and libmd. Then for each version run it against the src tree (or ports, either way) 10 times. Discard the first and last, and then plot the results with ministat. > If we really cared about the MD5 performance of applications linked > against libmd (including md5(1)), we should just optimize that MD5 > implementation rather than working around it. If it turns out that it's slower, that's a valid option as long as it happens soon'ish. :) > Also for csup, fixing the problem that is causing it to fetch whole > files over and over again likely would improve its performance way > more than using a different MD5 implementation could do. "There are other problems with this program" is not a good reason to add a pessimization. But let's find out if it is a pessimization before we worry about that. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On Mon, Dec 26, 2011 at 3:43 PM, Doug Barton wrote: > Then for each version run it > against the src tree (or ports, either way) 10 times. Discard the first > and last, and then plot the results with ministat. We discard the first to do warm cache benchmarks but why discard the last? Also see http://wiki.freebsd.org/BenchmarkAdvice?highlight=%28benchmarking%29 -- Eitan Adler ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On 12/26/2011 13:24, Eitan Adler wrote: > On Mon, Dec 26, 2011 at 3:43 PM, Doug Barton wrote: >> Then for each version run it >> against the src tree (or ports, either way) 10 times. Discard the first >> and last, and then plot the results with ministat. > > We discard the first to do warm cache benchmarks but why discard the last? Because the East German judge is always too brutal. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228904 - in head: contrib/groff/tmac lib lib/libstdthreads
Author: ed
Date: Mon Dec 26 21:51:53 2011
New Revision: 228904
URL: http://svn.freebsd.org/changeset/base/228904
Log:
Add libstdthreads.
This library implements the C11 threads interface on top of the pthreads
library. As discussed on the lists, the preferred way to implement
this, is as a separate library.
It is unlikely that these functions will be used a lot in the future. It
would have been easier if the C11 working group standardized (a subset
of) pthreads and clock_nanosleep(). Having it as a separate library
allows the embedded people to omit it from their system.
Discussed on: arch@, threads@
Added:
head/lib/libstdthreads/
head/lib/libstdthreads/Makefile (contents, props changed)
head/lib/libstdthreads/Symbol.map (contents, props changed)
head/lib/libstdthreads/call_once.c (contents, props changed)
head/lib/libstdthreads/cnd.c (contents, props changed)
head/lib/libstdthreads/mtx.c (contents, props changed)
head/lib/libstdthreads/thrd.c (contents, props changed)
head/lib/libstdthreads/thrd_create.3 (contents, props changed)
head/lib/libstdthreads/threads.h (contents, props changed)
head/lib/libstdthreads/tss.c (contents, props changed)
Modified:
head/contrib/groff/tmac/doc-syms
head/contrib/groff/tmac/groff_mdoc.man
head/lib/Makefile
Modified: head/contrib/groff/tmac/doc-syms
==
--- head/contrib/groff/tmac/doc-symsMon Dec 26 19:41:46 2011
(r228903)
+++ head/contrib/groff/tmac/doc-symsMon Dec 26 21:51:53 2011
(r228904)
@@ -814,6 +814,7 @@
.ds doc-str-Lb-librt \*[Px] \*[doc-str-Lb]Real-time Library (librt,
\-lrt)
.ds doc-str-Lb-libsdp Bluetooth Service Discovery Protocol User Library
(libsdp, \-lsdp)
.ds doc-str-Lb-libssp Buffer Overflow Protection Library (libssp, \-lssp)
+.ds doc-str-Lb-libstdthreads C11 Threads Library (libstdthreads, \-lstdthreads)
.ds doc-str-Lb-libSystem System Library (libSystem, \-lSystem)
.ds doc-str-Lb-libtermcap Termcap Access Library (libtermcap, \-ltermcap)
.ds doc-str-Lb-libterminfo Terminal Information Library (libterminfo,
\-lterminfo)
Modified: head/contrib/groff/tmac/groff_mdoc.man
==
--- head/contrib/groff/tmac/groff_mdoc.man Mon Dec 26 19:41:46 2011
(r228903)
+++ head/contrib/groff/tmac/groff_mdoc.man Mon Dec 26 21:51:53 2011
(r228904)
@@ -1797,6 +1797,8 @@ and their results are:
.Lb libsdp
.It Li libssp
.Lb libssp
+.It Li libstdthreads
+.Lb libstdthreads
.It Li libSystem
.Lb libSystem
.It Li libtermcap
Modified: head/lib/Makefile
==
--- head/lib/Makefile Mon Dec 26 19:41:46 2011(r228903)
+++ head/lib/Makefile Mon Dec 26 21:51:53 2011(r228904)
@@ -101,6 +101,7 @@ SUBDIR= ${SUBDIR_ORDERED} \
${_libsmdb} \
${_libsmutil} \
libstand \
+ libstdthreads \
${_libtelnet} \
${_libthr} \
libthread_db \
Added: head/lib/libstdthreads/Makefile
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libstdthreads/Makefile Mon Dec 26 21:51:53 2011
(r228904)
@@ -0,0 +1,41 @@
+# $FreeBSD$
+
+LIB= stdthreads
+SHLIB_MAJOR= 0
+
+INCS= threads.h
+SRCS= threads.h call_once.c cnd.c mtx.c thrd.c tss.c
+
+MAN= thrd_create.3
+MLINKS=thrd_create.3 call_once.3 \
+ thrd_create.3 cnd_broadcast.3 \
+ thrd_create.3 cnd_destroy.3 \
+ thrd_create.3 cnd_init.3 \
+ thrd_create.3 cnd_signal.3 \
+ thrd_create.3 cnd_timedwait.3 \
+ thrd_create.3 cnd_wait.3 \
+ thrd_create.3 mtx_destroy.3 \
+ thrd_create.3 mtx_init.3 \
+ thrd_create.3 mtx_lock.3 \
+ thrd_create.3 mtx_timedlock.3 \
+ thrd_create.3 mtx_trylock.3 \
+ thrd_create.3 mtx_unlock.3 \
+ thrd_create.3 thrd_current.3 \
+ thrd_create.3 thrd_detach.3 \
+ thrd_create.3 thrd_equal.3 \
+ thrd_create.3 thrd_exit.3 \
+ thrd_create.3 thrd_join.3 \
+ thrd_create.3 thrd_sleep.3 \
+ thrd_create.3 thrd_yield.3 \
+ thrd_create.3 tss_create.3 \
+ thrd_create.3 tss_delete.3 \
+ thrd_create.3 tss_get.3 \
+ thrd_create.3 tss_set.3
+
+DPADD= ${LIBPTHREAD}
+LDADD= -lpthread
+
+VERSION_DEF= ${.CURDIR}/../libc/Versions.def
+SYMBOL_MAPS= ${.CURDIR}/Symbol.map
+
+.include
Added: head/lib/libstdthreads/Symbol.map
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libstdthreads/Symbol.map Mon Dec 26 21:51:53 2011
(r228904)
@@ -0,0 +1,31 @@
+/*
+ * $FreeBSD$
+ */
+
+FBSD_1.3 {
+ call_once;
+ cnd_broadcast;
+ cnd_de
svn commit: r228905 - in vendor/libarchive/dist: . cpio libarchive libarchive/test libarchive_fe tar tar/test
Author: mm
Date: Mon Dec 26 22:25:58 2011
New Revision: 228905
URL: http://svn.freebsd.org/changeset/base/228905
Log:
Update to vendor revision 3982
Obtained from:http://libarchive.googlecode.com/svn/release/2.8
Added:
vendor/libarchive/dist/libarchive/test/test_compat_zip_2.zip.uu (contents,
props changed)
Modified:
vendor/libarchive/dist/CMakeLists.txt
vendor/libarchive/dist/cpio/bsdcpio.1
vendor/libarchive/dist/cpio/cmdline.c
vendor/libarchive/dist/cpio/cpio.c
vendor/libarchive/dist/cpio/cpio.h
vendor/libarchive/dist/libarchive/archive.h
vendor/libarchive/dist/libarchive/archive_entry.3
vendor/libarchive/dist/libarchive/archive_private.h
vendor/libarchive/dist/libarchive/archive_read.3
vendor/libarchive/dist/libarchive/archive_read.c
vendor/libarchive/dist/libarchive/archive_read_disk.3
vendor/libarchive/dist/libarchive/archive_read_disk.c
vendor/libarchive/dist/libarchive/archive_read_extract.c
vendor/libarchive/dist/libarchive/archive_read_support_format_cpio.c
vendor/libarchive/dist/libarchive/archive_read_support_format_iso9660.c
vendor/libarchive/dist/libarchive/archive_read_support_format_zip.c
vendor/libarchive/dist/libarchive/archive_util.3
vendor/libarchive/dist/libarchive/archive_virtual.c
vendor/libarchive/dist/libarchive/archive_write.3
vendor/libarchive/dist/libarchive/archive_write.c
vendor/libarchive/dist/libarchive/archive_write_disk.3
vendor/libarchive/dist/libarchive/archive_write_disk.c
vendor/libarchive/dist/libarchive/archive_write_set_format_cpio.c
vendor/libarchive/dist/libarchive/cpio.5
vendor/libarchive/dist/libarchive/libarchive-formats.5
vendor/libarchive/dist/libarchive/libarchive.3
vendor/libarchive/dist/libarchive/tar.5
vendor/libarchive/dist/libarchive/test/test_acl_freebsd.c
vendor/libarchive/dist/libarchive/test/test_compat_zip.c
vendor/libarchive/dist/libarchive_fe/pathmatch.c
vendor/libarchive/dist/tar/bsdtar.1
vendor/libarchive/dist/tar/read.c
vendor/libarchive/dist/tar/test/test_option_s.c
vendor/libarchive/dist/tar/tree.c
vendor/libarchive/dist/tar/util.c
vendor/libarchive/dist/tar/write.c
Modified: vendor/libarchive/dist/CMakeLists.txt
==
--- vendor/libarchive/dist/CMakeLists.txt Mon Dec 26 21:51:53 2011
(r228904)
+++ vendor/libarchive/dist/CMakeLists.txt Mon Dec 26 22:25:58 2011
(r228905)
@@ -857,12 +857,6 @@ INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRE
IF(MSVC)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
ENDIF(MSVC)
-# Especially for early development, we want to be a little
-# aggressive about diagnosing build problems; this can get
-# relaxed somewhat in final shipping versions.
-IF ("CMAKE_C_COMPILER_ID" MATCHES "^GNU$")
- ADD_DEFINITIONS(-Wall -Werror)
-ENDIF ("CMAKE_C_COMPILER_ID" MATCHES "^GNU$")
IF(ENABLE_TEST)
ADD_CUSTOM_TARGET(run_all_tests)
Modified: vendor/libarchive/dist/cpio/bsdcpio.1
==
--- vendor/libarchive/dist/cpio/bsdcpio.1 Mon Dec 26 21:51:53 2011
(r228904)
+++ vendor/libarchive/dist/cpio/bsdcpio.1 Mon Dec 26 22:25:58 2011
(r228905)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd December 21, 2007
+.Dd September 5, 2010
.Dt BSDCPIO 1
.Os
.Sh NAME
@@ -140,7 +140,7 @@ The POSIX.1 tar format.
The default format is
.Ar odc .
See
-.Xr libarchive_formats 5
+.Xr libarchive-formats 5
for more complete information about the
formats currently supported by the underlying
.Xr libarchive 3
@@ -295,7 +295,7 @@ for more information.
.Sh EXAMPLES
The
.Nm
-command is traditionally used to copy file heirarchies in conjunction
+command is traditionally used to copy file hierarchies in conjunction
with the
.Xr find 1
command.
Modified: vendor/libarchive/dist/cpio/cmdline.c
==
--- vendor/libarchive/dist/cpio/cmdline.c Mon Dec 26 21:51:53 2011
(r228904)
+++ vendor/libarchive/dist/cpio/cmdline.c Mon Dec 26 22:25:58 2011
(r228905)
@@ -285,6 +285,8 @@ cpio_getopt(struct cpio *cpio)
* A period can be used instead of the colon.
*
* Sets uid/gid return as appropriate, -1 indicates uid/gid not specified.
+ * TODO: If the spec uses uname/gname, then return those to the caller
+ * as well. If the spec provides uid/gid, just return names as NULL.
*
* Returns NULL if no error, otherwise returns error string for display.
*
Modified: vendor/libarchive/dist/cpio/cpio.c
==
--- vendor/libarchive/dist/cpio/cpio.c Mon Dec 26 21:51:53 2011
(r228904)
+++ vendor/libarchive/dist/cpio/cpio.c Mon Dec 26 22:25:58 2011
(r228905)
@@ -273,15 +273,21 @@ main(int argc, char *argv[])
cpio->quiet = 1;
break;
Re: svn commit: r228857 - in head/usr.bin: . csup
On Mon, Dec 26, 2011 at 12:43:07PM -0800, Doug Barton wrote: > On 12/26/2011 02:28, Marius Strobl wrote: > > On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: > >> On 12/24/2011 04:16, Marius Strobl wrote: > >>> On FreeBSD just use the MD5 implementation of libmd rather than that of > >>> libcrypto so we don't need to relinquish csup when world is built > >>> without > >>> OpenSSL. > >> > >> Did you benchmark this at all? I agree that keeping csup available > >> absent openssl is a good goal, but csup is a prototypical "tool that > >> does the same thing many thousands of times" so even tiny regressions > >> could add up to a large cost in wall clock time. > > > > Well, in a real world test updating the same base on an amd64 machine > > connected to the Internet > > Adding a network connection to the test is almost certainly going to > obscure the results beyond utility. Given that the majority of FreeBSD users will be pulling code from the internet, this seems to be the most relevant test. > The appropriate way to test this > would be to create a binary out of the md5 routine in csup, and link it > alternately with libcrypto and libmd. Then for each version run it > against the src tree (or ports, either way) 10 times. Discard the first > and last, and then plot the results with ministat. The proper way to test the libmd vs libcrypto versions of the md5 routines is to use a profiler. Of course, one might ask the question on how the use of libmd effects the majority of FreeBSD users (ie., not FreeBSD developers). Does the majority run csup hourly? Daily? Weekly? For a utility seldomly run be the majority of FreeBSD users, Doug, you seem to be wasting Marius's time. -- Steve ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On 12/26/2011 14:51, Steve Kargl wrote: > On Mon, Dec 26, 2011 at 12:43:07PM -0800, Doug Barton wrote: >> On 12/26/2011 02:28, Marius Strobl wrote: >>> On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: On 12/24/2011 04:16, Marius Strobl wrote: > On FreeBSD just use the MD5 implementation of libmd rather than that of > libcrypto so we don't need to relinquish csup when world is built > without > OpenSSL. Did you benchmark this at all? I agree that keeping csup available absent openssl is a good goal, but csup is a prototypical "tool that does the same thing many thousands of times" so even tiny regressions could add up to a large cost in wall clock time. >>> >>> Well, in a real world test updating the same base on an amd64 machine >>> connected to the Internet >> >> Adding a network connection to the test is almost certainly going to >> obscure the results beyond utility. > > Given that the majority of FreeBSD users will be pulling code > from the internet, this seems to be the most relevant test. Sorry if I wasn't clear. The change was to how the md5 portion of csup is linked. In order to isolate the effects of that change you have to remove everything that isn't related to that change. But this is regression testing 101, so I'm sure that you know that already. >> The appropriate way to test this >> would be to create a binary out of the md5 routine in csup, and link it >> alternately with libcrypto and libmd. Then for each version run it >> against the src tree (or ports, either way) 10 times. Discard the first >> and last, and then plot the results with ministat. > > The proper way to test the libmd vs libcrypto versions of > the md5 routines is to use a profiler. That'll give you a good view of where the performance bottlenecks are if it turns out that libmd is actually slower, sure. But the interesting question in terms of this change is the effect on wall clock time, since that's what users are going to see. > Of course, one might ask the question on how the use of > libmd effects the majority of FreeBSD users (ie., not FreeBSD > developers). Does the majority run csup hourly? Daily? > Weekly? For those that use csup, I imagine that they use it at least daily. But that's not the point. > For a utility seldomly run be the majority of FreeBSD > users, Doug, you seem to be wasting Marius's time. How often it's used isn't really relevant to whether or not introducing a pessimization is worth it. In any case I didn't ask him to back it out, I only asked to have it be an option if it turns out that libmd is slower. I understand that what you're really trying to do here is to take a shot at me relative to my assertion that profiled libs should be off by default. If you're going to respond in kind to every message I send it's going to get boring really quick. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r228906 - head/include
Author: ed
Date: Mon Dec 26 23:33:41 2011
New Revision: 228906
URL: http://svn.freebsd.org/changeset/base/228906
Log:
Fix some bugs in .
- Make atomic_init() work for GCC, as assigning to structs doesn't work.
- Fix misplaced parenthesis in atomic_is_lock_free() for GCC.
- Make atomic_compare_exchange_strong() for GCC return the proper
boolean value, whether object == expected.
- Fix argument passing in atomic_exchange_explicit() for GCC.
Modified:
head/include/stdatomic.h
Modified: head/include/stdatomic.h
==
--- head/include/stdatomic.hMon Dec 26 22:25:58 2011(r228905)
+++ head/include/stdatomic.hMon Dec 26 23:33:41 2011(r228906)
@@ -54,7 +54,9 @@
#defineatomic_init(obj, value) __atomic_init(obj, value)
#elif defined(__GNUC_ATOMICS)
#defineATOMIC_VAR_INIT(value) { .__val = (value) }
-#defineatomic_init(obj, value) (obj = ATOMIC_VAR_INIT(value))
+#defineatomic_init(obj, value) do {
\
+ (obj)->__val = (value); \
+} while (0)
#endif
/*
@@ -116,7 +118,7 @@ enum memory_order {
#if defined(__CLANG_ATOMICS)
#defineatomic_is_lock_free(obj)__atomic_is_lock_free(obj)
#elif defined(__GNUC_ATOMICS)
-#defineatomic_is_lock_free(obj)(sizeof((obj->__val)) <=
sizeof(void *))
+#defineatomic_is_lock_free(obj)(sizeof((obj)->__val) <=
sizeof(void *))
#endif
/*
@@ -200,12 +202,13 @@ typedef _Atomic(__uintmax_t) atomic_uin
#defineatomic_compare_exchange_strong_explicit(object, expected,
\
desired, success, failure) ({ \
__typeof__((object)->__val) __v;\
- __v = \
- __sync_val_compare_and_swap((__typeof(&((object)->__val)))object,\
- *expected, desired);\
- *expected = __v;\
- (*expected == __v); \
- })
+ _Bool __r; \
+ __v = __sync_val_compare_and_swap(&(object)->__val, \
+ *(expected), desired); \
+ __r = *(expected) == __v; \
+ *(expected) = __v; \
+ __r;\
+})
#defineatomic_compare_exchange_weak_explicit(object, expected,
\
desired, success, failure) \
@@ -223,7 +226,7 @@ typedef _Atomic(__uintmax_t)atomic_uin
*/
#defineatomic_exchange_explicit(object, desired, order) ({
\
__typeof__((object)->__val) __v;\
- __v = __sync_lock_test_and_set(object, desired);\
+ __v = __sync_lock_test_and_set(&(object)->__val, desired); \
__sync_synchronize(); \
__v;\
})
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On Mon, Dec 26, 2011 at 03:27:39PM -0800, Doug Barton wrote: > On 12/26/2011 14:51, Steve Kargl wrote: > > On Mon, Dec 26, 2011 at 12:43:07PM -0800, Doug Barton wrote: > >> On 12/26/2011 02:28, Marius Strobl wrote: > >>> On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: > On 12/24/2011 04:16, Marius Strobl wrote: > > On FreeBSD just use the MD5 implementation of libmd rather than that > > of > > libcrypto so we don't need to relinquish csup when world is built > > without > > OpenSSL. > > Did you benchmark this at all? I agree that keeping csup available > absent openssl is a good goal, but csup is a prototypical "tool that > does the same thing many thousands of times" so even tiny regressions > could add up to a large cost in wall clock time. > >>> > >>> Well, in a real world test updating the same base on an amd64 machine > >>> connected to the Internet > >> > >> Adding a network connection to the test is almost certainly going to > >> obscure the results beyond utility. > > > > Given that the majority of FreeBSD users will be pulling code > > from the internet, this seems to be the most relevant test. > > Sorry if I wasn't clear. The change was to how the md5 portion of csup > is linked. In order to isolate the effects of that change you have to > remove everything that isn't related to that change. > > But this is regression testing 101, so I'm sure that you know that already. If 99% of the usage of csup goes over the internet and 95% of the execution time (as determined by a profiler) involves dealing with network, then worrying about libmd vs libcrypto is a waste of time. If you're concerned about performance, then find the bottlenecks for that most common usage pattern. Micro-optimizing a synthetic usage case is a waste of time. > >> The appropriate way to test this > >> would be to create a binary out of the md5 routine in csup, and link it > >> alternately with libcrypto and libmd. Then for each version run it > >> against the src tree (or ports, either way) 10 times. Discard the first > >> and last, and then plot the results with ministat. > > > > The proper way to test the libmd vs libcrypto versions of > > the md5 routines is to use a profiler. > > That'll give you a good view of where the performance bottlenecks are if > it turns out that libmd is actually slower, sure. But the interesting > question in terms of this change is the effect on wall clock time, since > that's what users are going to see. > > > Of course, one might ask the question on how the use of > > libmd effects the majority of FreeBSD users (ie., not FreeBSD > > developers). Does the majority run csup hourly? Daily? > > Weekly? > > For those that use csup, I imagine that they use it at least daily. But > that's not the point. > > > For a utility seldomly run be the majority of FreeBSD > > users, Doug, you seem to be wasting Marius's time. > > How often it's used isn't really relevant to whether or not introducing > a pessimization is worth it. In any case I didn't ask him to back it > out, I only asked to have it be an option if it turns out that libmd is > slower. Yes, I know you did not ask him to back out his change. You asked him if he measured the impact on performance with that implication that he should run some performance test. Marius ran additional tests (wasting his time) to answer your question. Your response was essentially, "well, your really need to do the test this way (ie., no internet)", with the obvious implication of "please go do your test again." > I understand that what you're really trying to do here is to take a shot > at me relative to my assertion that profiled libs should be off by > default. If you're going to respond in kind to every message I send it's > going to get boring really quick. Nope. I'm concerned that your wasting valuable developer time. If you were really concerned with the performance, I suspect that you know how to do the tests you have asked of Marius. Now, let's read his commit message: On FreeBSD just use the MD5 implementation of libmd rather than that of libcrypto so we don't need to relinquish csup when world is built without OpenSSL. His change actually allows FreeBSD users to use csup if they are in a situation where WITHOUT_CRYPTO and/or WITHOUT_OPENSSL is required. Yes, I know you want him to waste his time to come up with the perfect patch with Makefile magic to find libcrypto and fall back to libmd. If you're really concerned about performance I'm fairly certain that Marius would be willing to review your Makefile magic patch. -- Steve ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228857 - in head/usr.bin: . csup
On 12/26/2011 16:09, Steve Kargl wrote: > On Mon, Dec 26, 2011 at 03:27:39PM -0800, Doug Barton wrote: >> On 12/26/2011 14:51, Steve Kargl wrote: >>> On Mon, Dec 26, 2011 at 12:43:07PM -0800, Doug Barton wrote: On 12/26/2011 02:28, Marius Strobl wrote: > On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: >> On 12/24/2011 04:16, Marius Strobl wrote: >>> On FreeBSD just use the MD5 implementation of libmd rather than that >>> of >>> libcrypto so we don't need to relinquish csup when world is built >>> without >>> OpenSSL. >> >> Did you benchmark this at all? I agree that keeping csup available >> absent openssl is a good goal, but csup is a prototypical "tool that >> does the same thing many thousands of times" so even tiny regressions >> could add up to a large cost in wall clock time. > > Well, in a real world test updating the same base on an amd64 machine > connected to the Internet Adding a network connection to the test is almost certainly going to obscure the results beyond utility. >>> >>> Given that the majority of FreeBSD users will be pulling code >>> from the internet, this seems to be the most relevant test. >> >> Sorry if I wasn't clear. The change was to how the md5 portion of csup >> is linked. In order to isolate the effects of that change you have to >> remove everything that isn't related to that change. >> >> But this is regression testing 101, so I'm sure that you know that already. > > If 99% of the usage of csup goes over the internet and 95% of the > execution time (as determined by a profiler) involves dealing with > network, Those are both completely theoretical of course. > then worrying about libmd vs libcrypto is a waste of time. This is really getting boring now. If a change makes performance worse it shouldn't be made without a really good reason. There is absolutely nothing controversial about that. > Yes, I know you did not ask him to back out his change. You asked > him if he measured the impact on performance with that implication > that he should run some performance test. Marius ran additional > tests (wasting his time) to answer your question. Your response > was essentially, "well, your really need to do the test this way > (ie., no internet)", with the obvious implication of "please go > do your test again." If Marius was confused about what I was asking him to test, or he didn't understand how to properly test his change, he should have asked. The fact that he did some kind of test that didn't actually demonstrate anything useful isn't my problem. >> I understand that what you're really trying to do here is to take a shot >> at me relative to my assertion that profiled libs should be off by >> default. If you're going to respond in kind to every message I send it's >> going to get boring really quick. > > Nope. I'm concerned that your wasting valuable developer time. And I'm concerned about wasting the time of every FreeBSD user that uses csup. > If you > were really concerned with the performance, I suspect that you know > how to do the tests you have asked of Marius. I'm not the one proposing to make the change, he is. It's up to HIM to demonstrate that his change is moving us in the right direction. > Now, let's read his commit message: > > On FreeBSD just use the MD5 implementation of libmd rather than > that of libcrypto so we don't need to relinquish csup when world > is built without OpenSSL. I read his commit message, I understand what he's trying to accomplish. > His change actually allows FreeBSD users to use csup if they are > in a situation where WITHOUT_CRYPTO and/or WITHOUT_OPENSSL is > required. Personally I've never seen anyone mention this as a problem. > Yes, I know you want him to waste his time to come > up with the perfect patch with Makefile magic to find libcrypto > and fall back to libmd. If you're really concerned about > performance I'm fairly certain that Marius would be willing > to review your Makefile magic patch. You're still missing the fundamental point that the person proposing the change is the one who needs to demonstrate that the change is the right way to go. Imagine that the scenario was reversed. You would no doubt be demanding that I provide extensive evidence that my change was correct. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
