From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 04:54:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B1C1065670 for ; Sun, 27 Feb 2011 04:54:55 +0000 (UTC) (envelope-from daniloegea@yahoo.com.br) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by mx1.freebsd.org (Postfix) with SMTP id 547C38FC0C for ; Sun, 27 Feb 2011 04:54:55 +0000 (UTC) Received: from [98.139.91.61] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 04:42:37 -0000 Received: from [98.139.91.57] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 04:42:37 -0000 Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 04:42:37 -0000 X-Yahoo-Newman-Id: 625648.59122.bm@omp1057.mail.sp2.yahoo.com Received: (qmail 88057 invoked from network); 27 Feb 2011 04:42:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=TkD03lHaHAowM9YW2KaQMKyqLx+dLoZMiYojVF2x+vH2x1pIdk0g0itubdFwOKXCV5ld2bKRV86o6y6rSMdex9JPFxEvL/53ZU36Hwn974QZpcVgjTlk/84Vs82aG2o96IvVGhMvPUL+T0RhLQidLKUVczgzi9qzGnjylSaP7m0= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1298781757; bh=UM5wnilRomMNUW09aEXxXhzOL/uyHLwm6WA6LTprIHQ=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=dmXyt/Okjewv5VZTFNgslTy28TkrQBEaBQPiojr/lmaa9vo2vZfgYMp1sEf8nbPG5F2UpL/n4TJW54SF/XtdL6uWVM7KGDjPGdf5Dva378arVeqnaKTg2zN2T3XNJEEW4csPHpIB1YHALIzoMWbmFoyPxUVlvpYZHGWLLOvm0eQ= Received: from bb17b10c.virtua.com.br (daniloegea@187.23.177.12 with plain) by smtp143.mail.mud.yahoo.com with SMTP; 26 Feb 2011 20:42:36 -0800 PST X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- X-YMail-OSG: l2hpWLQVM1nHc4_7rs9IEEWhW.ocKgtcCf15t20lpTIejd2 vNJUDBw7JOrV4oG7RHWPSic_odO.9OrCbDwX0uhxP24diordV45rfD62BuD. tA2qjx1.8D9aFUY.RziNK6ztj.fZJxbn5z2B4rmMCYGc3AqqZRJuoUchftC2 iJvxTe7sPYc2dBO5fUBDlkTIhwM4ScUU6ukmIKdVpKDKuIXz45wA.4UMQBL5 URCBIPkzQHRO7gJs35QVcUNAwLDvgGK8rBpfGiLafw2k4vFOAs6.OjirJH3K f7RwljQg44ofMcAvBG6wviKL7dJyW8E0d5y_0AlF56kc96UIlFy0x8nc_w6P ckJ1mtULZ86LnaJ0KxzrDPOohqjYdpG8lLPXG9ZOrDtfwPaE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D69D639.1010505@yahoo.com.br> Date: Sun, 27 Feb 2011 01:42:33 -0300 From: Danilo Egea User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: libdispatch don't build on 8.2-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 04:54:55 -0000 Hi guys, Anyone know what's going on? PS: with clang-devel libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC -DPIC -o .libs/time.o libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o time.o >/dev/null 2>&1 mv -f .deps/time.Tpo .deps/time.Plo /bin/sh ../libtool --tag=CC --mode=link clang -fPIC -o libshims.la mach.lo time.lo -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o libtool: link: ranlib .libs/libshims.a libtool: link: ( cd ".libs" && rm -f "libshims.la" && ln -s "../libshims.la" "libshims.la" ) /bin/sh ../libtool --tag=CC --mode=link clang -Wall -fblocks -fPIC -o libdispatch.la -rpath /usr/local/lib libdispatch_la-apply.lo libdispatch_la-benchmark.lo libdispatch_la-object.lo libdispatch_la-once.lo libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo libdispatch_la-semaphore.lo libdispatch_la-source.lo libdispatch_la-source_kevent.lo libdispatch_la-time.lo libshims.la -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: clang -shared .libs/libdispatch_la-apply.o .libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o .libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o .libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o .libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o .libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a -Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime -Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 /usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. *** Error code 1 Stop in /usr/ports/devel/libdispatch. *** Error code 1 Stop in /usr/ports/devel/libdispatch. -- Danilo Egêa Gondolfo http://daniloegea.wordpress.com From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 17:37:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40DEF1065670 for ; Sun, 27 Feb 2011 17:37:14 +0000 (UTC) (envelope-from daniloegea@yahoo.com.br) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id 1425C8FC1C for ; Sun, 27 Feb 2011 17:37:13 +0000 (UTC) Received: from [98.139.91.68] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 17:37:13 -0000 Received: from [98.139.91.29] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 17:37:13 -0000 Received: from [127.0.0.1] by omp1029.mail.sp2.yahoo.com with NNFMP; 27 Feb 2011 17:37:13 -0000 X-Yahoo-Newman-Id: 787378.78189.bm@omp1029.mail.sp2.yahoo.com Received: (qmail 70650 invoked from network); 27 Feb 2011 17:37:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yYTTN1sDyaBYk1jReM905tN8o7fsERgtrwL41D60uPRstcdsRye5NEfenXPuUF/1u8OQE6MdmaCGUfCQEgoOs5vcRu0+P8q91v0eH9CFgh5mpNWhtIUwMS3r3I+qZsa9dOT8Y3qFMvk8bXeH/6IsLiPVx32Y51Tg6eC5H9j47ic= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1298828233; bh=NuHx/URsSIiQG0DNrGRzTL2XG4rgoEF9NHWnVRW+nAo=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jTb9W6lQVV7djxqdM3CzeVYd1PDjmUc7wT64nzyKVFUn6ebT7vKrwoW3r8zmlKfLxPkTdIfXlIRfQOYaVp8SVR9afN1+P+IElgxWYdRco2Tui6sn9sYnM56HSzCaceX1j0OiRsOiTYmJbFetqfvftBKxfUPX1EhEPrxfTh3eLx8= Received: from barba.local (daniloegea@187.23.176.56 with plain) by smtp135.mail.mud.yahoo.com with SMTP; 27 Feb 2011 09:37:12 -0800 PST X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- X-YMail-OSG: 3rUA1.4VM1lAS_PSBKJnmoWVpi4NR6AaEnxjl19_5u5seZc M2_ydzlQrCQ0QsSaWNJsczL1fO09n8kOzTW2GI6QINZFI7_qm5eGcVdb6qfB bqcaLeRw.1Zl7.zNFt_X.0qVo_1nm5iCcx5ozVWLxkg0YVU1BTpkd0UftfYs MSsRXHS0qCEiR4UjH0H1gXoe26Di_kXdEdta1Z82ct4jU279B497me0K2Nmw OtolLdfZz4vj3kpeHlhu1jViF_NUncajj9EKGBFdbdhpCuHQie4vRKs_MsMt M3.682Q.bwf2L3YT2NnqyM5SV4T.ca8MTXl3MFvOdjaoizRUwdohIzgQAE_v A.HbMPnUWT4B8ECjjhFVrFaRjlgJmlNm28oR3LBpYu8xd3rc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6A8BC6.1030409@yahoo.com.br> Date: Sun, 27 Feb 2011 14:37:10 -0300 From: Danilo Egea User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D69D639.1010505@yahoo.com.br> In-Reply-To: <4D69D639.1010505@yahoo.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: libdispatch don't build on 8.2-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 17:37:14 -0000 Worked with GCC, but support blocks is disabled... :( On 2/27/11 1:42 AM, Danilo Egea wrote: > Hi guys, > > Anyone know what's going on? > > PS: with clang-devel > > libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. > -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC > -DPIC -o .libs/time.o > libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. > -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o time.o > >/dev/null 2>&1 > mv -f .deps/time.Tpo .deps/time.Plo > /bin/sh ../libtool --tag=CC --mode=link clang -fPIC -o > libshims.la mach.lo time.lo -lpthread -L/usr/local/lib -lBlocksRuntime > libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o > libtool: link: ranlib .libs/libshims.a > libtool: link: ( cd ".libs" && rm -f "libshims.la" && ln -s > "../libshims.la" "libshims.la" ) > /bin/sh ../libtool --tag=CC --mode=link clang -Wall -fblocks > -fPIC -o libdispatch.la -rpath /usr/local/lib > libdispatch_la-apply.lo libdispatch_la-benchmark.lo > libdispatch_la-object.lo libdispatch_la-once.lo > libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo > libdispatch_la-semaphore.lo libdispatch_la-source.lo > libdispatch_la-source_kevent.lo libdispatch_la-time.lo libshims.la > -lpthread -L/usr/local/lib -lBlocksRuntime > libtool: link: clang -shared .libs/libdispatch_la-apply.o > .libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o > .libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o > .libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o > .libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o > .libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a > -Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime > -Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 > /usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation > R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used > when making a shared object; recompile with -fPIC > /usr/local/bin/ld: final link failed: Bad value > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. > *** Error code 1 > > Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. > *** Error code 1 > > Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. > *** Error code 1 > > Stop in /usr/ports/devel/libdispatch. > *** Error code 1 > > Stop in /usr/ports/devel/libdispatch. > -- Danilo Egêa Gondolfo http://daniloegea.wordpress.com __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 20:54:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFD3C106566C for ; Sun, 27 Feb 2011 20:54:45 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1B98FC22 for ; Sun, 27 Feb 2011 20:54:45 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1RKpqTs067497 for ; Sun, 27 Feb 2011 12:51:53 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D6ABA14.80208@rawbw.com> Date: Sun, 27 Feb 2011 12:54:44 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 20:54:45 -0000 On FreeBSD-8.1 this page says: The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. On Linux it says: The /pthread_cond_signal/() function shall unblock at least one of the threads that are blocked on the specified condition variable /cond/ (if any threads are blocked on /cond/). Also HP page (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: "If there are no threads blocked on /cond/, this function has no effect." And later it says: "It is possible that more than one thread can be unblocked due to a spurious wakeup." This is quite confusing: in case nobody is waiting does it block or not? In case other threads are waiting it's really "any arbitrary number of threads are woken up"? Or on FreeBSD it's strictly 1? Shouldn't this be defined in one and only way by POSIX and all POSIX-compliant systems should work exactly the same. I think man page should be expanded to give more comprehensive explanation. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 21:26:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42D481065672 for ; Sun, 27 Feb 2011 21:26:20 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2E24E8FC16 for ; Sun, 27 Feb 2011 21:26:19 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1RLNRoG073241; Sun, 27 Feb 2011 13:23:27 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D6AC17A.7020505@rawbw.com> Date: Sun, 27 Feb 2011 13:26:18 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6ABA14.80208@rawbw.com> In-Reply-To: <4D6ABA14.80208@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , standards@freebsd.org, davidxu@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 21:26:20 -0000 Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. Also I want to add that I came to this question while observing behavior consistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded code that assumes that only one thread can be woken up by one pthread_cond_signal call crashes, and the only reasonable explanation so far is that more than one threads are actually being woken up. Yuri On 02/27/2011 12:54, Yuri wrote: > On FreeBSD-8.1 this page says: > The pthread_cond_signal() function unblocks one thread waiting for the > condition variable cond. > > On Linux it says: > The /pthread_cond_signal/() function shall unblock at least one of the > threads that are blocked on the specified condition variable /cond/ > (if any threads are blocked on /cond/). > > Also HP page > (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: > "If there are no threads blocked on /cond/, this function has no > effect." And later it says: "It is possible that more than one thread > can be unblocked due to a spurious wakeup." > > This is quite confusing: in case nobody is waiting does it block or > not? In case other threads are waiting it's really "any arbitrary > number of threads are woken up"? Or on FreeBSD it's strictly 1? > Shouldn't this be defined in one and only way by POSIX and all > POSIX-compliant systems should work exactly the same. > > I think man page should be expanded to give more comprehensive > explanation. > > Yuri > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 01:33:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7E5131065670; Mon, 28 Feb 2011 01:33:01 +0000 (UTC) Date: Mon, 28 Feb 2011 01:33:01 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110228013301.GA74220@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223235355.GA48790@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 01:33:01 -0000 On Wed Feb 23 11, Garrett Cooper wrote: > On Wed, Feb 23, 2011 at 3:53 PM, Alexander Best wrote: > > On Wed Feb 23 11, Garrett Cooper wrote: > >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > >> > >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > >> >> (Please bottom post) > >> >> > >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > >> >>> I thought seeking past EOF was valid; writing something creates a file > >> > with a hole in it. I always assumed that was standard semantics. > >> >> > >> >>    That's with SET_HOLE/SET_DATA though, correct? If so, outside of > >> >> that functionality I would assume relatively standard POSIX semantics. > >> > > >> > Err, no, you can always seek past EOF and then call write(2) to extend a file > >> > (it does an implicit ftruncate(2)).  SEEK_HOLE and SEEK_DATA are different, > >> > they are just used to discover sparse regions within a file. > > > > on the other hand POSIX says: > > > > "The behavior of lseek() on devices which are incapable of seeking is implementation-defined. > > The value of the file offset associated with such a device is undefined." > > > > ...if we define /dev/{zero,null} as incapable of seeking the current > > implementation should be ok. > > > >> > > >> > From the manpage: > >> > > >> >     The lseek() system call allows the file offset to be set beyond the end > >> >     of the existing end-of-file of the file.  If data is later written at > >> >     this point, subsequent reads of the data in the gap return bytes of zeros > >> >     (until data is actually written into the gap). > >> > >>       You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): > >> > >> The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. > > Yes, but look at how it's defined by POSIX before you do that > (yes, there's a section for null/zero IIRC). i cannot find any references to null/zero in connection with seeking in the POSIX specs. > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 02:00:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41856106566B; Mon, 28 Feb 2011 02:00:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2FEBC8FC15; Mon, 28 Feb 2011 02:00:58 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1S20u5i087494; Mon, 28 Feb 2011 02:00:57 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D6B01DB.9090909@freebsd.org> Date: Mon, 28 Feb 2011 10:00:59 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110127 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yuri References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> In-Reply-To: <4D6AC17A.7020505@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 02:00:58 -0000 On 2011/02/28 05:26, Yuri wrote: > Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. > > Also I want to add that I came to this question while observing behavior > consistent with multiple wakeup on FreeBSD-8.1. The heavily > multi-threaded code that assumes that only one thread can be woken up by > one pthread_cond_signal call crashes, and the only reasonable > explanation so far is that more than one threads are actually being > woken up. > > Yuri > > > On 02/27/2011 12:54, Yuri wrote: >> On FreeBSD-8.1 this page says: >> The pthread_cond_signal() function unblocks one thread waiting for the >> condition variable cond. >> >> On Linux it says: >> The /pthread_cond_signal/() function shall unblock at least one of the >> threads that are blocked on the specified condition variable /cond/ >> (if any threads are blocked on /cond/). >> >> Also HP page >> (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: >> "If there are no threads blocked on /cond/, this function has no >> effect." And later it says: "It is possible that more than one thread >> can be unblocked due to a spurious wakeup." >> >> This is quite confusing: in case nobody is waiting does it block or >> not? In case other threads are waiting it's really "any arbitrary >> number of threads are woken up"? Or on FreeBSD it's strictly 1? >> Shouldn't this be defined in one and only way by POSIX and all >> POSIX-compliant systems should work exactly the same. >> >> I think man page should be expanded to give more comprehensive >> explanation. >> >> Yuri >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> It is really not important if pthread_cond_signal wake up one thread or multiple threads in corner case, because POSIX said: --- When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. --- I think in normal case, pthread_cond_signal will wake up one thread, but other events for example, UNIX signal and fork() may interrupt a thread sleeping in kernel, and cause pthread_cond_wait to return to userland, this is called spurious wakeup, and other events, I can not think of yet, but I believe they exist. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 02:26:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D95B3106566B; Mon, 28 Feb 2011 02:26:35 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 92D4E8FC1A; Mon, 28 Feb 2011 02:26:35 +0000 (UTC) Received: from [10.0.0.19] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p1S2CWLf013661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Feb 2011 21:12:33 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sun, 27 Feb 2011 21:12:33 -0500 (EST) References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> In-Reply-To: <4D6AC17A.7020505@rawbw.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Daniel Eischen Date: Sun, 27 Feb 2011 21:12:30 -0500 To: Yuri Cc: Garrett Cooper , "freebsd-hackers@freebsd.org" , "standards@freebsd.org" , "davidxu@freebsd.org" Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 02:26:35 -0000 On Feb 27, 2011, at 4:26 PM, Yuri wrote: > Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. >=20 > Also I want to add that I came to this question while observing behavior c= onsistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded co= de that assumes that only one thread can be woken up by one pthread_cond_sig= nal call crashes, and the only reasonable explanation so far is that more th= an one threads are actually being woken up. It depends on what you mean by wakeup. More than one thread may unblock, bu= t only one thread will have the mutex locked after wakeup. If other threads= awake (as allowed by POSIX), they will have to check the state protected by= the mutex to see if they really should awake and continue or if they shoul= d block again on the CV. A wakeup from pthread_cond_wait() should not assum= e that he was the only thread awoken. -- DE= From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 02:41:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE591106566C for ; Mon, 28 Feb 2011 02:41:47 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 536B08FC14 for ; Mon, 28 Feb 2011 02:41:46 +0000 (UTC) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.160.140]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p1S29uGJ009484; Mon, 28 Feb 2011 03:09:56 +0100 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Mon, 28 Feb 2011 03:09:56 +0100 User-Agent: KMail/1.9.10 References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> In-Reply-To: <4D6AC17A.7020505@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102280309.56631.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Yuri Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 02:41:47 -0000 On Sunday 27 February 2011 22:26:18 Yuri wrote: > Also I want to add that I came to this question while observing behavior > consistent with multiple wakeup on FreeBSD-8.1. The heavily > multi-threaded code that assumes that only one thread can be woken up by > one pthread_cond_signal call crashes, and the only reasonable > explanation so far is that more than one threads are actually being > woken up. pthread_cond_signal() can indeed wake up more than one thread. That's why you should always wrap pthread_cond_wait() in a loop. For example a blocking queue could be implemented like this (pseudo code): take() { pthread_mutex_lock(mutex); while(queue->empty()) { pthread_cond_wait(cond, mutex); } item = queue->get(); pthread_mutex_unlock(mutex); return item; } put(item) { pthread_mutex_lock(mutex); queue->put(item); pthread_cond_signal(cond); pthread_mutex_unlock(mutex); } pthread_cond_signal() itself never blocks. Hope this helps. -- Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 15:08:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C261065672 for ; Mon, 28 Feb 2011 15:08:38 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 755EB8FC18 for ; Mon, 28 Feb 2011 15:08:38 +0000 (UTC) Received: from MacBook.local (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1SF5eqL009862; Mon, 28 Feb 2011 07:05:41 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D6BBA70.8010503@rawbw.com> Date: Mon, 28 Feb 2011 07:08:32 -0800 From: Yuri User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <201102280309.56631.pieter@degoeje.nl> In-Reply-To: <201102280309.56631.pieter@degoeje.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pieter de Goeje Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:08:38 -0000 On 28.02.11 2:41, Pieter de Goeje wrote: > pthread_cond_signal() can indeed wake up more than one thread. That's why you > should always wrap pthread_cond_wait() in a loop. For example a blocking > queue could be implemented like this (pseudo code): Thank you. Now its clear that POSIX allows multiple wake ups. But my question is: why would the standard define it this way? Why would it allow essentially arbitrary number of waiting threads to be woken up by one event? I can't think of any practical app that would need "some threads to be woken up". It would be natural to expect it to wake exactly one thread. So the users won't need to have any special cycles like you suggested in your previous post. What is the underlying reason for POSIX to define it this way and for OSes to implement it this way? Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 15:39:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51486106564A for ; Mon, 28 Feb 2011 15:39:47 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx1.utsp.utwente.nl [130.89.2.12]) by mx1.freebsd.org (Postfix) with ESMTP id C93E28FC15 for ; Mon, 28 Feb 2011 15:39:46 +0000 (UTC) Received: from pieter-dev.localnet (lux.student.utwente.nl [130.89.161.112]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p1SFdeBh004795; Mon, 28 Feb 2011 16:39:40 +0100 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Mon, 28 Feb 2011 16:39:39 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) References: <4D6ABA14.80208@rawbw.com> <201102280309.56631.pieter@degoeje.nl> <4D6BBA70.8010503@rawbw.com> In-Reply-To: <4D6BBA70.8010503@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102281639.40151.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Yuri Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:39:47 -0000 On Monday 28 February 2011 16:08:32 Yuri wrote: > On 28.02.11 2:41, Pieter de Goeje wrote: > > pthread_cond_signal() can indeed wake up more than one thread. That's why > > you should always wrap pthread_cond_wait() in a loop. For example a > > blocking > > > queue could be implemented like this (pseudo code): > Thank you. Now its clear that POSIX allows multiple wake ups. > > But my question is: why would the standard define it this way? Why would > it allow essentially arbitrary number of waiting threads to be woken up > by one event? I can't think of any practical app that would need "some > threads to be woken up". It would be natural to expect it to wake > exactly one thread. So the users won't need to have any special cycles > like you suggested in your previous post. > > What is the underlying reason for POSIX to define it this way and for > OSes to implement it this way? Well you need the extra cycles anyway because pthread_cond_wait() can wakeup for no apparent reason. As David Xu explained, in FreeBSD this can for instance happen because a signal is delivered to the process or the process called fork(). For pthread library implementors its probably easier (faster) to guarantee that at least one thread will be woken by pthread_cond_signal() instead of exactly one. Because the application needs to check the condition's predicate anyway it's logical to allow for a more relaxed specification. In that sense, pthread_cond_signal() is only here because it is a lot faster than calling pthread_cond_broadcast() all the time (because of the thundering herd problem). - Pieter From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 05:41:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBA621065675 for ; Tue, 1 Mar 2011 05:41:01 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by mx1.freebsd.org (Postfix) with ESMTP id 616B28FC15 for ; Tue, 1 Mar 2011 05:41:01 +0000 (UTC) Received: from edtncm03 ([199.185.220.221]) by priv-edtnes24.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110301044052.IQHA18968.priv-edtnes24.telusplanet.net@edtncm03> for ; Mon, 28 Feb 2011 21:40:52 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edtncm03 with bizsmtp id Dggs1g00W3VzCbE01ggsHi; Mon, 28 Feb 2011 21:40:52 -0700 X-Authority-Analysis: v=1.1 cv=/MstOKohVXLcoh41OzLGLG1pGanowbNkwUlbTYXu0H8= c=1 sm=2 a=gsKcAFrldNcA:10 a=8nJEP1OIZ-IA:10 a=M5uFTj07sYmvjh8Bt1MA:9 a=DKej-0hZnK8QlQAwCmAA:7 a=F88puE2vYOyd4MSwb1UbH-3DwTAA:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id 02908645E; Mon, 28 Feb 2011 20:40:51 -0800 (PST) Message-ID: <4D6C78D3.5090803@telus.net> Date: Mon, 28 Feb 2011 20:40:51 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Mar 2011 05:56:36 +0000 Subject: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:41:01 -0000 Kernel drivers can be (and in at least one case are) compiled into the kernel but are not reported when queried for, at least not in a way that I am aware of. For example, the ucom driver is present in the GENERIC kernel in this way. My expectation was that "kldstat -v" would list it, if present, but it does not. A design flaw? # ls /boot/kernel/ucom.ko /boot/kernel/ucom.ko # grep ucom /usr/src/sys/i386/conf/GENERIC # kldstat -v | grep ucom # kldload ucom.ko # tail -n 1 /var/log/messages Feb 28 18:18:15 xxxxxx kernel: interface ucom.1 already present in the KLD 'kernel'! How does one query an existing kernel for *all* compiled-in modules? I'm using FreeBSD-8.1-RELEASE-amd64/i386. Carl / K0802647 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 11:49:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667E11065678 for ; Tue, 1 Mar 2011 11:49:28 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id DF1A78FC0A for ; Tue, 1 Mar 2011 11:49:27 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-192.lns6.adl6.internode.on.net [203.122.198.192]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p21BnH8m089217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Mar 2011 22:19:19 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4D6C78D3.5090803@telus.net> Date: Tue, 1 Mar 2011 22:19:17 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> References: <4D6C78D3.5090803@telus.net> To: Carl X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:49:28 -0000 On 01/03/2011, at 15:10, Carl wrote: > Kernel drivers can be (and in at least one case are) compiled into the = kernel but are not reported when queried for, at least not in a way that = I am aware of. For example, the ucom driver is present in the GENERIC = kernel in this way. My expectation was that "kldstat -v" would list it, = if present, but it does not. A design flaw? Sounds like a bug, but I'm not sure where.. Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() = declaration (because it isn't a driver). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 12:03:31 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 185EB1065675 for ; Tue, 1 Mar 2011 12:03:31 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F00A8FC08 for ; Tue, 1 Mar 2011 12:03:30 +0000 (UTC) Received: by eyg7 with SMTP id 7so1803292eyg.13 for ; Tue, 01 Mar 2011 04:03:29 -0800 (PST) Received: by 10.213.14.20 with SMTP id e20mr2503206eba.28.1298981009361; Tue, 01 Mar 2011 04:03:29 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id q52sm4132039eei.3.2011.03.01.04.03.28 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 04:03:28 -0800 (PST) Message-ID: <4D6CE08F.6060103@my.gd> Date: Tue, 01 Mar 2011 13:03:27 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6C78D3.5090803@telus.net> In-Reply-To: <4D6C78D3.5090803@telus.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:03:31 -0000 On 3/1/11 5:40 AM, Carl wrote: > Kernel drivers can be (and in at least one case are) compiled into the > kernel but are not reported when queried for, at least not in a way that > I am aware of. For example, the ucom driver is present in the GENERIC > kernel in this way. My expectation was that "kldstat -v" would list it, > if present, but it does not. A design flaw? > > # ls /boot/kernel/ucom.ko > /boot/kernel/ucom.ko > # grep ucom /usr/src/sys/i386/conf/GENERIC > # kldstat -v | grep ucom > # kldload ucom.ko > # tail -n 1 /var/log/messages > Feb 28 18:18:15 xxxxxx kernel: interface ucom.1 already present in the > KLD 'kernel'! > > How does one query an existing kernel for *all* compiled-in modules? > > I'm using FreeBSD-8.1-RELEASE-amd64/i386. > > Carl / K0802647 > Well AFAIK kldstat -v should return them all... Also, as a side note to your question, find below an excerpt from ucom's man page: SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ucom Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ucom_load="YES" So indeed if you want it statically in the kernel, you need to add "device ucom" Have you tried doing that, building again then querying again with kldstat -v ? From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 11:47:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F1C91065672 for ; Tue, 1 Mar 2011 11:47:51 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50DDE8FC08 for ; Tue, 1 Mar 2011 11:47:50 +0000 (UTC) Received: by vws16 with SMTP id 16so4675851vws.13 for ; Tue, 01 Mar 2011 03:47:50 -0800 (PST) Received: by 10.220.117.198 with SMTP id s6mr924010vcq.127.1298978459376; Tue, 01 Mar 2011 03:20:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.42.67 with HTTP; Tue, 1 Mar 2011 03:20:29 -0800 (PST) In-Reply-To: <4D6C78D3.5090803@telus.net> References: <4D6C78D3.5090803@telus.net> From: Maxim Khitrov Date: Tue, 1 Mar 2011 06:20:29 -0500 Message-ID: To: Carl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Mar 2011 12:16:54 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:47:51 -0000 On Mon, Feb 28, 2011 at 11:40 PM, Carl wrote: > Kernel drivers can be (and in at least one case are) compiled into the > kernel but are not reported when queried for, at least not in a way that = I > am aware of. For example, the ucom driver is present in the GENERIC kerne= l > in this way. My expectation was that "kldstat -v" would list it, if prese= nt, > but it does not. A design flaw? > > # ls /boot/kernel/ucom.ko > /boot/kernel/ucom.ko > # grep ucom /usr/src/sys/i386/conf/GENERIC > # kldstat -v | grep ucom > # kldload ucom.ko > # tail -n 1 /var/log/messages > Feb 28 18:18:15 xxxxxx kernel: interface ucom.1 already present in the KL= D > 'kernel'! > > How does one query an existing kernel for *all* compiled-in modules? > > I'm using FreeBSD-8.1-RELEASE-amd64/i386. > > Carl =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / K0802647 kldstat provides information about components that were loaded dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option (enabled by default in GENERIC), then you can see the static components using: config -x /boot/kernel/kernel See config(8) for more details. - Max From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 12:24:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8100A1065673 for ; Tue, 1 Mar 2011 12:24:48 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 11A7C8FC17 for ; Tue, 1 Mar 2011 12:24:48 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id ECDF3E902C; Tue, 1 Mar 2011 12:24:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=MxbN5jJc8+W/ AvX5pxB2Uw0hv9M=; b=setzWIlBhVn7sScnBGfh5nFbc/FaCXreO8yuuF39qYZB 1GRng7YWutlniZAkIvdJY9hZQq441izDIK1TFt6xfM8smeFc4hdxMRPUurZPEoBD jH8VaVQsHW7nQzZM6znypwmDE/0yIq4DLwjkPdnroRcuiGHreo4/nXKDNgB9z5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=tixPQy Xe4MCRSGR3LVVDuV1DFIZ2XemnfYKzBdgT+OtR95MmkL7ak9i7S4NKLnMR8U2ThJ ahVCAxz3RkR5k0W1/o5JaY7ff0XMZL8/7LWj2pNMMcwm3UVXdefwjTKmEDX/Qn9V gNYpuhzRHxpRef/3WGDI9PEVQRJB0e12jP8ag= Received: from unknown (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 91EB6E8150; Tue, 1 Mar 2011 12:24:46 +0000 (GMT) Date: Tue, 1 Mar 2011 12:24:17 +0000 From: Bruce Cran To: Maxim Khitrov Message-ID: <20110301122417.00000c88@unknown> In-Reply-To: References: <4D6C78D3.5090803@telus.net> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Carl , freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:24:48 -0000 On Tue, 1 Mar 2011 06:20:29 -0500 Maxim Khitrov wrote: > kldstat provides information about components that were loaded > dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option > (enabled by default in GENERIC), then you can see the static > components using: It seems it can also list static components: > kldstat -v Id Refs Address Size Name 1 1 0xc0400000 4c51b4 kernel (/boot/kernel/kernel) Contains modules: Id Name 95 if_lo 86 elf32 87 shell 96 igmp 97 mld 90 sysvmsg 91 sysvsem [...] -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 13:19:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5522D1065676 for ; Tue, 1 Mar 2011 13:19:48 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E5E968FC1B for ; Tue, 1 Mar 2011 13:19:45 +0000 (UTC) Received: by ewy28 with SMTP id 28so1829186ewy.13 for ; Tue, 01 Mar 2011 05:19:44 -0800 (PST) Received: by 10.14.127.136 with SMTP id d8mr4813449eei.35.1298985584691; Tue, 01 Mar 2011 05:19:44 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id b52sm4197070eei.7.2011.03.01.05.19.43 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 05:19:43 -0800 (PST) Message-ID: <4D6CF26E.3020602@my.gd> Date: Tue, 01 Mar 2011 14:19:42 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6C78D3.5090803@telus.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:19:48 -0000 On 3/1/11 12:20 PM, Maxim Khitrov wrote: > On Mon, Feb 28, 2011 at 11:40 PM, Carl wrote: >> Kernel drivers can be (and in at least one case are) compiled into the >> kernel but are not reported when queried for, at least not in a way that I >> am aware of. For example, the ucom driver is present in the GENERIC kernel >> in this way. My expectation was that "kldstat -v" would list it, if present, >> but it does not. A design flaw? >> >> # ls /boot/kernel/ucom.ko >> /boot/kernel/ucom.ko >> # grep ucom /usr/src/sys/i386/conf/GENERIC >> # kldstat -v | grep ucom >> # kldload ucom.ko >> # tail -n 1 /var/log/messages >> Feb 28 18:18:15 xxxxxx kernel: interface ucom.1 already present in the KLD >> 'kernel'! >> >> How does one query an existing kernel for *all* compiled-in modules? >> >> I'm using FreeBSD-8.1-RELEASE-amd64/i386. >> >> Carl / K0802647 > > kldstat provides information about components that were loaded > dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option > (enabled by default in GENERIC), then you can see the static > components using: > > config -x /boot/kernel/kernel > > See config(8) for more details. > > - Max kldstat also shows statically compiled modules, example below. Here's my kldstat: # kldstat Id Refs Address Size Name 1 16 0xffffffff80100000 91f9f8 kernel 2 1 0xffffffff80a20000 bbd8 geom_label.ko 3 1 0xffffffff80a2c000 21058 geom_mirror.ko 4 1 0xffffffff80a4e000 f078 aio.ko 5 1 0xffffffff80c22000 104d42 zfs.ko 6 1 0xffffffff80d27000 f217 krpc.ko 7 1 0xffffffff80d37000 1a15 opensolaris.ko Now, looking for my network card: # kldstat -v |grep bce 65 pci/bce 64 bce/miibus From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 14:49:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E511065670 for ; Tue, 1 Mar 2011 14:49:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 604AE8FC1B for ; Tue, 1 Mar 2011 14:49:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1A2AA46B2D; Tue, 1 Mar 2011 09:49:41 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B134F8A02A; Tue, 1 Mar 2011 09:49:40 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 1 Mar 2011 08:00:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6C78D3.5090803@telus.net> <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> In-Reply-To: <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103010800.35666.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Mar 2011 09:49:40 -0500 (EST) Cc: Carl Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:49:41 -0000 On Tuesday, March 01, 2011 6:49:17 am Daniel O'Connor wrote: > > On 01/03/2011, at 15:10, Carl wrote: > > Kernel drivers can be (and in at least one case are) compiled into the kernel but are not reported when queried for, at least not in a way that I am aware of. For example, the ucom driver is present in the GENERIC kernel in this way. My expectation was that "kldstat -v" would list it, if present, but it does not. A design flaw? > > Sounds like a bug, but I'm not sure where.. > > Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() declaration (because it isn't a driver). Yes, that would explain it. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:20:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC511065676 for ; Tue, 1 Mar 2011 20:20:04 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound04.telus.net [199.185.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 89CBD8FC14 for ; Tue, 1 Mar 2011 20:20:04 +0000 (UTC) Received: from edtncm04 ([199.185.220.240]) by priv-edtnes29.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110301200150.JALA21021.priv-edtnes29.telusplanet.net@edtncm04> for ; Tue, 1 Mar 2011 13:01:50 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edtncm04 with bizsmtp id Dw1p1g01N3VzCbE01w1p06; Tue, 01 Mar 2011 13:01:50 -0700 X-Authority-Analysis: v=1.1 cv=Hhb8vUndaQ9JqXo/Swdf63bQvjw2wPrzWawgI51+Yeo= c=1 sm=2 a=ZLM83dXrbFwA:10 a=8nJEP1OIZ-IA:10 a=rHoXDY67BRVrmH2fTW0A:9 a=j9p2Z7CruMOcpaaC82kIcMyc44EA:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id 154606455; Tue, 1 Mar 2011 12:01:49 -0800 (PST) Message-ID: <4D6D50AC.701@telus.net> Date: Tue, 01 Mar 2011 12:01:48 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6C78D3.5090803@telus.net> <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> <201103010800.35666.jhb@freebsd.org> In-Reply-To: <201103010800.35666.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Mar 2011 20:30:43 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:20:05 -0000 On 2011-03-01 3:20 AM, Maxim Khitrov wrote: > kldstat provides information about components that were loaded > dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option > (enabled by default in GENERIC), then you can see the static > components using: > > config -x /boot/kernel/kernel As has been shown though, "kldstat -v" actually does show static components, at least those declared with DRIVER_MODULE(), and "config -x" does not improve on the situation at all because components like ucom were not cited in the configuration file. IMHO, there needs to be a reliable way to query an existing kernel that yields a _complete_ list of which components are actually included. On 2011-03-01 5:00 AM, John Baldwin wrote: >> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() >> declaration (because it isn't a driver). > > Yes, that would explain it. I can explicitly include ucom in a kernel by adding "device ucom" in the configuration file, in which case it would call DRIVER_MODULE(), right? That would then make it appear in the "kldstat -v" list? So why is it a driver when it's done explicitly, but not a driver when done implicitly? That makes no sense to me since the functionality doesn't change. IMHO, this is a bug that needs to be fixed, not just for ucom but any implicitly included driver. Who should submit a bug report? Carl / K0802647 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:45:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EB5106566C; Tue, 1 Mar 2011 20:45:11 +0000 (UTC) (envelope-from jhelfman@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id BAED48FC0C; Tue, 1 Mar 2011 20:45:11 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 72C6F6F6058; Tue, 1 Mar 2011 12:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=ee; t= 1299012301; x=1300826701; bh=ZeI1N75w9XoXbhH0mI9/sA9RI5zXG9zDjeD r82E1KRM=; b=LSn7sMiAf/eyJIjv442isM7z1wKh13a7clw0xj17B1usdIoCN0X uOrSdhJI3BdpQHjx2qWWFCeOPwGwQICkomdOE3ajilSEbrj5Mcn5d54KxCD/DgiI Fx9Fm3NrpfVbJL2TakCOS9S8vHeGUwfba3BNXec/lm/zDA5OQwljyQtI= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bINScBkccP14; Tue, 1 Mar 2011 12:45:01 -0800 (PST) Received: from experts-exchange.com (unknown [72.29.180.81]) by mail.experts-exchange.com (Postfix) with SMTP id 8F86D6F6059; Tue, 1 Mar 2011 12:44:45 -0800 (PST) Received: (nullmailer pid 52449 invoked by uid 1001); Tue, 01 Mar 2011 20:41:24 -0000 Date: Tue, 1 Mar 2011 12:41:24 -0800 From: Jason Helfman To: Carl Message-ID: <20110301204124.GD76063@eggman.experts-exchange.com> References: <4D6C78D3.5090803@telus.net> <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> <201103010800.35666.jhb@freebsd.org> <4D6D50AC.701@telus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4D6D50AC.701@telus.net> X-Operating-System: FreeBSD 8.2-RELEASE X-Living-The-Dream: I love the SLO Life! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:45:12 -0000 On Tue, Mar 01, 2011 at 12:01:48PM -0800, Carl thus spake: >On 2011-03-01 3:20 AM, Maxim Khitrov wrote: >> kldstat provides information about components that were loaded >> dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option >> (enabled by default in GENERIC), then you can see the static >> components using: >> >> config -x /boot/kernel/kernel > >As has been shown though, "kldstat -v" actually does show static >components, at least those declared with DRIVER_MODULE(), and "config >-x" does not improve on the situation at all because components like >ucom were not cited in the configuration file. IMHO, there needs to be a >reliable way to query an existing kernel that yields a _complete_ list >of which components are actually included. > >On 2011-03-01 5:00 AM, John Baldwin wrote: >>> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() >>> declaration (because it isn't a driver). >> >> Yes, that would explain it. > >I can explicitly include ucom in a kernel by adding "device ucom" in the >configuration file, in which case it would call DRIVER_MODULE(), right? >That would then make it appear in the "kldstat -v" list? So why is it a >driver when it's done explicitly, but not a driver when done implicitly? >That makes no sense to me since the functionality doesn't change. IMHO, >this is a bug that needs to be fixed, not just for ucom but any >implicitly included driver. > >Who should submit a bug report? There was a documentation bug that was put in regarding the ucom device, and it was to update the device name in the documentation. http://www.freebsd.org/cgi/query-pr.cgi?pr=155074 I don't know if a PR is still required, but this may be worth a look first. > >Carl / K0802647 -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 22:54:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 710C5106566B for ; Tue, 1 Mar 2011 22:54:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id EC2138FC0A for ; Tue, 1 Mar 2011 22:54:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id p21MXJKM056795; Tue, 1 Mar 2011 15:33:19 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id p21MXIK3056792; Tue, 1 Mar 2011 15:33:19 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 1 Mar 2011 15:33:18 -0700 (MST) From: Warren Block To: Jason Helfman In-Reply-To: <20110301204124.GD76063@eggman.experts-exchange.com> Message-ID: References: <4D6C78D3.5090803@telus.net> <198718A4-4A82-4FDB-A8F6-400F132A649E@gsoft.com.au> <201103010800.35666.jhb@freebsd.org> <4D6D50AC.701@telus.net> <20110301204124.GD76063@eggman.experts-exchange.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Tue, 01 Mar 2011 15:33:19 -0700 (MST) Cc: Carl , freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:54:18 -0000 On Tue, 1 Mar 2011, Jason Helfman wrote: > On Tue, Mar 01, 2011 at 12:01:48PM -0800, Carl thus spake: >> >> I can explicitly include ucom in a kernel by adding "device ucom" in the >> configuration file, in which case it would call DRIVER_MODULE(), right? >> That would then make it appear in the "kldstat -v" list? So why is it a >> driver when it's done explicitly, but not a driver when done implicitly? >> That makes no sense to me since the functionality doesn't change. IMHO, >> this is a bug that needs to be fixed, not just for ucom but any >> implicitly included driver. >> >> Who should submit a bug report? > > There was a documentation bug that was put in regarding the ucom device, and > it was to update the device name in the documentation. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=155074 > > I don't know if a PR is still required, but this may be worth a look first. usb_quirk.4 appears to be a copy and edit of ucom.4. The device name edit was missed, so it still referred to ucom. I don't think this affects what you're talking about. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 00:35:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F61106564A for ; Wed, 2 Mar 2011 00:35:53 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 08D078FC24 for ; Wed, 2 Mar 2011 00:35:52 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p220ZJHw019339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 1 Mar 2011 16:35:52 -0800 (PST) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Mar 2011 16:35:52 -0800 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Wed, 02 Mar 2011 03:30:06 +0000 Subject: TaPP '11 Call for Contributions Now Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:35:53 -0000 The Program Committee for the 3rd Workshop on the Theory and Practice of Provenance (TaPP '11) invites you to submit short papers on ongoing work. TaPP '11 will bring together researchers and practitioners doing innovative work in the area of provenance. With the deluge of digital data we are currently experiencing, it has become increasingly important to capture and understand the origins and derivation of data--its provenance. Provenance provides important documentation that is an essential part of the quality of data, and it is essential to the trust we put in, for example, the data we find on the Web and the data that is derived from scientific experiments. The workshop may cover any topic related to theoretical or practical aspects of provenance, including but not limited to: provenance in databases, work flows, programming languages, security, software engineering, or systems; provenance on the Web; or real-world applications of or requirements for provenance. The Program Committee is determined to make TaPP '11 a real workshop at which new ideas are discussed and developed and where the participants can learn how other subjects make use of provenance. While the workshop will have online proceedings, the Committee does not want the workshop to become another "mini-conference" that has nothing but paper presentations. The Committee is eager to receive short papers and vision papers describing challenges for provenance research, brief descriptions of new applications, proposals for mini-tutorials, pie-in-the sky research ideas, and anything that will create a successful workshop. While brief and readable descriptions of research are encouraged, recycled conference submissions are strongly discouraged. Submissions are due April 8, 2011, at 11:59 p.m. PDT. More information and submission guidelines are available at http://www.usenix.org/tapp11/cfpa Tapp '11 will take place June 20-22, 2011, in Heraklion, Crete, Greece, the week after the meeting of ACM SIGMOD in Athens. We look forward to receiving your submissions! Sincerely, Peter Buneman, University of Edinburgh Juliana Freire, University of Utah TaPP '11 Program Co-Chairs tapp11chairs@usenix.org ------------------------------------------------------------------ TaPP '11 Call for Papers 3rd Workshop on the Theory and Practice of Provenance (TaPP '11) June 20-22, 2011, Heraklion, Crete, Greece http://www.usenix.org/tapp11/cfpa Submission deadline: April 8, 2011, 11:59 p.m. PDT ------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 10:41:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80C22106566C for ; Wed, 2 Mar 2011 10:41:27 +0000 (UTC) (envelope-from riaank@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9FE8FC17 for ; Wed, 2 Mar 2011 10:41:26 +0000 (UTC) Received: by wwb31 with SMTP id 31so7705968wwb.31 for ; Wed, 02 Mar 2011 02:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=rE+Q8Hduz0pEd4eNOu/2OCRlE9FJ1DLGJIWgBEGbbG4=; b=d0grnUPVgr3pW5TEHBJimZOSs/sv0dTRZDHZUjgGh63YwUtK2lK4MZjL84ZLvxd+PQ 2GciAutyW7pL/Vj7r5wh6HhAkJEz6gRukEFAVvqQBxlIMA7kKHmAkm6nGOj+SB6IhPqv M9Xov8yohZs5FgVUyF0DMcN8MCNQHPHN3RZFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=J6GgnjU2I/9zrfMFCN9hxGiieFQRa2PnE6wphhM2WtCp41O0XI5lxaW0tTeZ4wdNO8 WSedZePNWS5P9AziFrX3ljRtTSsMuog6GaowE6JXyeqCPAOBoX1L1vuQ0K+37n6uOHmh 5rXmmT46kaNS5fKBmmIKxxIHzHX3OVVmh3ELA= MIME-Version: 1.0 Received: by 10.227.147.14 with SMTP id j14mr7275630wbv.98.1299060890732; Wed, 02 Mar 2011 02:14:50 -0800 (PST) Received: by 10.227.149.195 with HTTP; Wed, 2 Mar 2011 02:14:50 -0800 (PST) Date: Wed, 2 Mar 2011 12:14:50 +0200 Message-ID: From: Riaan Kruger To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: AES-GCM in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 10:41:27 -0000 We wish to implement AES-GCM in the FreeBSD OCF whith the main aim of using it in IPsec [a]. I have a number of questions: 1. What mailing list is the most appropriate for questions and comments related to this subject? 2. What is the best way to share any work done? (pacthes to mailing list?) 3. Is it best to work of HEAD when implementing the solution? 4. We aim to port the work done for openbsd [b][c]. Does anybody know of any specific pitfalls, gotchas etc. when using this approach? (E.g.I assume the FreeBSD OCF has diverged from OpenBSDs over the years) [a] - RFC4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP), http://tools.ietf.org/html/rfc4106 [b] - AES-GCM Part 1: AES-GCM implementation, http://marc.info/?t=128233110500001&r=1&w=2 [c] - AES-GCM Part 2: PFKEY/ESP, http://marc.info/?t=128258773600009&r=1&w=2 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 12:56:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A23B106566B for ; Wed, 2 Mar 2011 12:56:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6C27C8FC17 for ; Wed, 2 Mar 2011 12:56:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1318A46B90; Wed, 2 Mar 2011 07:56:45 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9B8A48A01B; Wed, 2 Mar 2011 07:56:44 -0500 (EST) From: John Baldwin To: Carl Date: Tue, 1 Mar 2011 17:13:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6C78D3.5090803@telus.net> <201103010800.35666.jhb@freebsd.org> <4D6D50AC.701@telus.net> In-Reply-To: <4D6D50AC.701@telus.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103011713.40140.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Mar 2011 07:56:44 -0500 (EST) Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 12:56:45 -0000 On Tuesday, March 01, 2011 3:01:48 pm Carl wrote: > On 2011-03-01 3:20 AM, Maxim Khitrov wrote: > > kldstat provides information about components that were loaded > > dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option > > (enabled by default in GENERIC), then you can see the static > > components using: > > > > config -x /boot/kernel/kernel > > As has been shown though, "kldstat -v" actually does show static > components, at least those declared with DRIVER_MODULE(), and "config > -x" does not improve on the situation at all because components like > ucom were not cited in the configuration file. IMHO, there needs to be a > reliable way to query an existing kernel that yields a _complete_ list > of which components are actually included. > > On 2011-03-01 5:00 AM, John Baldwin wrote: > >> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() > >> declaration (because it isn't a driver). > > > > Yes, that would explain it. > > I can explicitly include ucom in a kernel by adding "device ucom" in the > configuration file, in which case it would call DRIVER_MODULE(), right? > That would then make it appear in the "kldstat -v" list? So why is it a > driver when it's done explicitly, but not a driver when done implicitly? > That makes no sense to me since the functionality doesn't change. IMHO, > this is a bug that needs to be fixed, not just for ucom but any > implicitly included driver. No, the _source_ code of device ucom has to explicitly say "I am a module named 'foo'" using a DECLARE_MODULE() macro (or another macro such as DRIVER_MODULE() that invokes DECLARE_MODULE()). The 'device ucom' in a config file does not generate this, that is just an instruction that config(8) uses when looking in sys/conf/files to see which C source files to include in the kernel build. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 15:31:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09061065672 for ; Wed, 2 Mar 2011 15:31:45 +0000 (UTC) (envelope-from daniloegea@yahoo.com.br) Received: from nm18-vm0.bullet.mail.ac4.yahoo.com (nm18-vm0.bullet.mail.ac4.yahoo.com [98.139.53.210]) by mx1.freebsd.org (Postfix) with SMTP id 9DEEB8FC08 for ; Wed, 2 Mar 2011 15:31:45 +0000 (UTC) Received: from [98.139.52.190] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 15:19:04 -0000 Received: from [98.139.52.177] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 15:19:04 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 15:19:04 -0000 X-Yahoo-Newman-Id: 670363.79521.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 44737 invoked from network); 2 Mar 2011 15:19:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SrBCsizbXVkezj0anYjfM1fzEyMpV2m+Kj1km5cj/h+/R/tPdJo9fIk1pV9Krnm0W3ntFXCj+3fy+iBBDlS076G6kO9jCfRuXTz6be+qRTBJ9j/hRSpIzBwuzcxt6ba1mk7ZbLY6u7Q2dZRJlhA4wNwnvoiU31ZswHn2u6EaROM= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1299079144; bh=J2Hh0YFG3GdOOh2b4dUJft7ZNifLL+SZBslLdDhwdQU=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GzZVkh5vmTMnkXRGYXf2uvgJ3nf2PURndHqzTMED0h3jG0OLNS9X6xBSWETVKhDWTlyiqZRt6RJb1gd1zbhYLNinVNfB4tBPEyUd8cdR6GVb2qmS3FHL8l5VEVAzt98WGcoKZBMc1fNuvBViV9uBm0H6R00VBKrO8Wgvnzl8Gks= Received: from barba.local (daniloegea@189.7.21.192 with plain) by smtp137.mail.mud.yahoo.com with SMTP; 02 Mar 2011 07:19:03 -0800 PST X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- X-YMail-OSG: _QL0zkMVM1nZFvmHkJchM6fI65obwt._.VI9PHyymiSaNid R8wGj.fHDraJC08bvEUIfwtbdtoyNgH_RMdkySw2TseoiWwwfJmGUctSkOk9 RPWWR0IcvYZNZ3TVIGVO_EK7grLIKRGXhtB2zejPIP1lB35zLERdfKLnoBQk zJNhqbU9.QNhx53aRW41.Kxz2w2Ztl0fx26ZTNR9ouyY_BLerwNCg8ZaRgJs MWK2OoKOoVBdL2z4Jun1W_23qWEzEJnEKzscJbMd2hFjWRp_Hf.uWFWbPDn_ vIF7WqLauBhBBFdalL64mpCbCKALH.QA1vSCqLv5X X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6E5FE5.3030306@yahoo.com.br> Date: Wed, 02 Mar 2011 12:19:01 -0300 From: Danilo Egea User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D69D639.1010505@yahoo.com.br> <4D6A8BC6.1030409@yahoo.com.br> In-Reply-To: <4D6A8BC6.1030409@yahoo.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: libdispatch don't build on 8.2-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:31:46 -0000 The problem is the binutils version, the port try to use the binutils-2.21. With the binutils-2.15 (native of the system) works fine. On 2/27/11 2:37 PM, Danilo Egea wrote: > Worked with GCC, but support blocks is disabled... :( > > On 2/27/11 1:42 AM, Danilo Egea wrote: >> Hi guys, >> >> Anyone know what's going on? >> >> PS: with clang-devel >> >> libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. >> -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC >> -DPIC -o .libs/time.o >> libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. >> -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o >> time.o >/dev/null 2>&1 >> mv -f .deps/time.Tpo .deps/time.Plo >> /bin/sh ../libtool --tag=CC --mode=link clang -fPIC -o >> libshims.la mach.lo time.lo -lpthread -L/usr/local/lib >> -lBlocksRuntime >> libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o >> libtool: link: ranlib .libs/libshims.a >> libtool: link: ( cd ".libs" && rm -f "libshims.la" && ln -s >> "../libshims.la" "libshims.la" ) >> /bin/sh ../libtool --tag=CC --mode=link clang -Wall -fblocks >> -fPIC -o libdispatch.la -rpath /usr/local/lib >> libdispatch_la-apply.lo libdispatch_la-benchmark.lo >> libdispatch_la-object.lo libdispatch_la-once.lo >> libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo >> libdispatch_la-semaphore.lo libdispatch_la-source.lo >> libdispatch_la-source_kevent.lo libdispatch_la-time.lo >> libshims.la -lpthread -L/usr/local/lib -lBlocksRuntime >> libtool: link: clang -shared .libs/libdispatch_la-apply.o >> .libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o >> .libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o >> .libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o >> .libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o >> .libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a >> -Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime >> -Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 >> /usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation >> R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used >> when making a shared object; recompile with -fPIC >> /usr/local/bin/ld: final link failed: Bad value >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> *** Error code 1 >> >> Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. >> *** Error code 1 >> >> Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. >> *** Error code 1 >> >> Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. >> *** Error code 1 >> >> Stop in /usr/ports/devel/libdispatch. >> *** Error code 1 >> >> Stop in /usr/ports/devel/libdispatch. >> > > -- Danilo Egêa Gondolfo http://daniloegea.wordpress.com __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 15:40:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF041065673 for ; Wed, 2 Mar 2011 15:40:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 055068FC17 for ; Wed, 2 Mar 2011 15:40:32 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p22FeOjs066571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 17:40:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p22FeOJ2040602; Wed, 2 Mar 2011 17:40:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p22FeO61040601; Wed, 2 Mar 2011 17:40:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Mar 2011 17:40:24 +0200 From: Kostik Belousov To: Danilo Egea Message-ID: <20110302154024.GD78089@deviant.kiev.zoral.com.ua> References: <4D69D639.1010505@yahoo.com.br> <4D6A8BC6.1030409@yahoo.com.br> <4D6E5FE5.3030306@yahoo.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVeLy+mkNfkgBwIW" Content-Disposition: inline In-Reply-To: <4D6E5FE5.3030306@yahoo.com.br> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: libdispatch don't build on 8.2-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:40:33 -0000 --iVeLy+mkNfkgBwIW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 02, 2011 at 12:19:01PM -0300, Danilo Egea wrote: > The problem is the binutils version, the port try to use the=20 > binutils-2.21. With the binutils-2.15 (native of the system) works fine. Rather, it is binutils 2.15 silently creating broken library. 2.21 refuses to do it. Some object used to create the final dso was not built with -fPIC. >=20 > On 2/27/11 2:37 PM, Danilo Egea wrote: > >Worked with GCC, but support blocks is disabled... :( > > > >On 2/27/11 1:42 AM, Danilo Egea wrote: > >>Hi guys, > >> > >>Anyone know what's going on? > >> > >>PS: with clang-devel > >> > >>libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I..=20 > >>-fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC=20 > >>-DPIC -o .libs/time.o > >>libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I..=20 > >>-fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o=20 > >>time.o >/dev/null 2>&1 > >>mv -f .deps/time.Tpo .deps/time.Plo > >>/bin/sh ../libtool --tag=3DCC --mode=3Dlink clang -fPIC -o=20 > >>libshims.la mach.lo time.lo -lpthread -L/usr/local/lib=20 > >>-lBlocksRuntime > >>libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o > >>libtool: link: ranlib .libs/libshims.a > >>libtool: link: ( cd ".libs" && rm -f "libshims.la" && ln -s=20 > >>"../libshims.la" "libshims.la" ) > >>/bin/sh ../libtool --tag=3DCC --mode=3Dlink clang -Wall -fblocks = =20 > >>-fPIC -o libdispatch.la -rpath /usr/local/lib=20 > >>libdispatch_la-apply.lo libdispatch_la-benchmark.lo=20 > >>libdispatch_la-object.lo libdispatch_la-once.lo=20 > >>libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo=20 > >>libdispatch_la-semaphore.lo libdispatch_la-source.lo=20 > >>libdispatch_la-source_kevent.lo libdispatch_la-time.lo =20 > >>libshims.la -lpthread -L/usr/local/lib -lBlocksRuntime > >>libtool: link: clang -shared .libs/libdispatch_la-apply.o=20 > >>.libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o=20 > >>.libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o=20 > >>.libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o=20 > >>.libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o=20 > >>.libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a=20 > >>-Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime = =20 > >>-Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 > >>/usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation=20 > >>R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used=20 > >>when making a shared object; recompile with -fPIC > >>/usr/local/bin/ld: final link failed: Bad value > >>clang: error: linker command failed with exit code 1 (use -v to see=20 > >>invocation) > >>*** Error code 1 > >> > >>Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. > >>*** Error code 1 > >> > >>Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. > >>*** Error code 1 > >> > >>Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. > >>*** Error code 1 > >> > >>Stop in /usr/ports/devel/libdispatch. > >>*** Error code 1 > >> > >>Stop in /usr/ports/devel/libdispatch. > >> > > > > >=20 >=20 > --=20 > Danilo Eg?a Gondolfo > http://daniloegea.wordpress.com >=20 > __________________________________________________ > Fale com seus amigos de gra?a com o novo Yahoo! Messenger=20 > http://br.messenger.yahoo.com/=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --iVeLy+mkNfkgBwIW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1uZOgACgkQC3+MBN1Mb4jXKQCdHm9Gil4LaNIHPhA53vt08kv5 W40AnjhidSBWsv34xpGSLXWs09XVbc3J =ytXD -----END PGP SIGNATURE----- --iVeLy+mkNfkgBwIW-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 20:45:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C524106566B; Wed, 2 Mar 2011 20:45:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3679B8FC16; Wed, 2 Mar 2011 20:45:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4df5:7675:40a8:361] (unknown [IPv6:2001:7b8:3a7:0:4df5:7675:40a8:361]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 56CD45C59; Wed, 2 Mar 2011 21:45:57 +0100 (CET) Message-ID: <4D6EAC8C.7010804@FreeBSD.org> Date: Wed, 02 Mar 2011 21:46:04 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110227 Lanikai/3.1.9pre MIME-Version: 1.0 To: Kostik Belousov References: <4D69D639.1010505@yahoo.com.br> <4D6A8BC6.1030409@yahoo.com.br> <4D6E5FE5.3030306@yahoo.com.br> <20110302154024.GD78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110302154024.GD78089@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------010902020307030105070700" Cc: Stanislav Sedov , freebsd-hackers@freebsd.org, Danilo Egea Subject: Re: libdispatch don't build on 8.2-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:45:58 -0000 This is a multi-part message in MIME format. --------------010902020307030105070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-03-02 16:40, Kostik Belousov wrote: > Rather, it is binutils 2.15 silently creating broken library. > 2.21 refuses to do it. > > Some object used to create the final dso was not built with -fPIC. This is actually a problem of clang, in combination with libdispatch's configure script. It tries to detect support for __private_extern__, which is an Apple extension that serves the same goal on Darwin as the visibility("hidden") attribute. If the test program does not compile, it just defines __private_extern__ as visibility("hidden") instead, if the toolchain supports that attribute. However, clang has a problem that it accepts the __private_extern__ attribute even on non-Darwin OSes, while *not* marking the symbol hidden. This will lead to the link error you are seeing here. Can you please try the attached patch, which is a bit of a hack, but works for now? Meanwhile, I'll prod the clang developers to disable recognition of __private_extern__ on non-Darwin platforms. --------------010902020307030105070700 Content-Type: text/plain; name="clang-devel-libdispatch-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clang-devel-libdispatch-1.diff" Index: devel/libdispatch/Makefile =================================================================== RCS file: /home/mirror/ncvs/ports/devel/libdispatch/Makefile,v retrieving revision 1.10 diff -u -r1.10 Makefile --- devel/libdispatch/Makefile 15 Dec 2009 21:06:37 -0000 1.10 +++ devel/libdispatch/Makefile 2 Mar 2011 20:26:28 -0000 @@ -86,8 +86,7 @@ RUN_DEPENDS+= clang:${PORTSDIR}/devel/llvm-devel \ ${LOCALBASE}/lib/libBlocksRuntime.so:${PORTSDIR}/devel/compiler-rt CONFIGURE_ARGS+= --with-blocks-runtime=/usr/local/lib -CONFIGURE_ENV+= CC="clang" -MAKE_ENV+= CC="clang" +CONFIGURE_ENV+= CC="clang" dispatch_cv_private_extern="no" .endif .include --------------010902020307030105070700-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 22:25:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9249F1065672 for ; Wed, 2 Mar 2011 22:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 441D88FC16 for ; Wed, 2 Mar 2011 22:25:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9D89841C679; Wed, 2 Mar 2011 23:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id irGTxWviOAZR; Wed, 2 Mar 2011 23:25:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DB94641C7A8; Wed, 2 Mar 2011 23:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9C4DC4448FC; Wed, 2 Mar 2011 22:20:39 +0000 (UTC) Date: Wed, 2 Mar 2011 22:20:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Dirk Engling In-Reply-To: <4D5AC7F1.7020501@erdgeist.org> Message-ID: <20110302221932.T13400@maildrop.int.zabbadoz.net> References: <4D5AC7F1.7020501@erdgeist.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Detecting listening servers in multi-ip jails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:25:07 -0000 On Tue, 15 Feb 2011, Dirk Engling wrote: > Hello, > > until jails could be bound to several ip addresses, my convenience > feature in ezjail to check for and warn about listening services in the > host system and other jails worked simply by asking: > > listeners_ip=`sockstat -4 -l | grep "${ip}:[[:digit:]]"` > listeners_all=`sockstat -4 -l | grep "*:[[:digit:]]"` > > Now where ip adresses are not rewritten on listen() calls anymore, > services in jails can bind to 0.0.0.0 as well and will match the latter, > although they don't really cause the trouble I want to warn users about > (unless, of course the jail really is bound to the same ip address and > the service then binds to 0.0.0.0). > > Now I can, using "nc -z", test if the service really listens. That > allows me to filter and only report those services that actually > respond. However, this is far from clean. > > Are there other ways to relibly test for listening services on any port > for a given ip address? get the pid and use a cross-check on the process; there is no easy way do it otherwise currently unless you write your own extensions needing kvm. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 23:19:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8E9C106566C for ; Wed, 2 Mar 2011 23:19:12 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7556A8FC08 for ; Wed, 2 Mar 2011 23:19:12 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p22NIRrK023577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 Mar 2011 15:19:12 -0800 (PST) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Mar 2011 15:19:12 -0800 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Wed, 02 Mar 2011 23:48:19 +0000 Subject: HotCloud '11 Submission Deadline Extended X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:19:12 -0000 The submission deadline for the 3rd USENIX Workshop on Hot Topics in Cloud Computing (HotCloud '11) has been extended to accommodate the HotOS XIII schedule. Please submit your work by March 14, 2011, at 11:59 p.m. EDT. http://papers.usenix.org/hotcrp/hotcloud11/ HotCloud brings together researchers and practitioners from academia and industry working on cloud computing technologies. There are many challenges in the design, implementation, and deployment of cloud computing, such as automated service provisioning, service monitoring and management, resource elasticity and interference/isolation between users, cloud programming models, economic models, charging and accounting, and service creation using virtual appliances. We believe that cloud computing will benefit from close interaction between researchers and industry practitioners, so that the research can inform current deployments and deployment challenges can inform new research. In support of this, HotCloud will provide a forum for both academics and practitioners to share their experience, leverage each other's perspectives, and identify new/emerging "hot" trends in this important area. Topics of interest include but are not limited to the following: * Platform as a service * Software as a service * Infrastructure as a service * Elasticity and availability in a cloud * Multi-tenancy * Storage cloud * Charging models and economics * Power-efficient ("green") computing for clouds * Monitoring, troubleshooting, and failure recovery * Cloud management and configuration * Programming models * Virtual appliance management and composition * Security and privacy in clouds * New applications for clouds * Mobile clouds * Cloud usage scenarios For more details on the submission process, please see the complete Call for Papers at http://www.usenix.org/hotcloud11/cfpb We look forward to receiving your submissions! Ion Stoica, University of California, Berkeley John Wilkes, Google HotCloud '11 Program Co-Chairs hotcloud11chairs@usenix.org --------------------------------- Call for Papers 3rd USENIX Workshop on Hot Topics in Cloud Computing (HotCloud '11) June 14, 2011 Portland, OR, USA Part of USENIX Federated Conferences Week, June 14-17, 2011 http://www.usenix.org/hotcloud11/cfpb Submission Deadline: March 14, 2011, 11:59 p.m. EDT From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 08:03:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1080A106566B for ; Thu, 3 Mar 2011 08:03:11 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.30]) by mx1.freebsd.org (Postfix) with ESMTP id A27518FC08 for ; Thu, 3 Mar 2011 08:03:10 +0000 (UTC) Received: from edmwcm03 ([204.209.205.13]) by priv-edmwes51.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110303080304.SYFZ9447.priv-edmwes51.telusplanet.net@edmwcm03> for ; Thu, 3 Mar 2011 01:03:04 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edmwcm03 with bizsmtp id EY331g01Z3VzCbE01Y33Dc; Thu, 03 Mar 2011 01:03:04 -0700 X-Telus-Outbound-IP: 66.183.53.162 X-Authority-Analysis: v=1.1 cv=X9rcaziX+10GahXZ2mN8brc3QgEqBDtfVyXTeyj1OEU= c=1 sm=2 a=ZLM83dXrbFwA:10 a=8nJEP1OIZ-IA:10 a=Pean2klS5YVZkl_le0QA:9 a=CrpXPcH4N2Nhui53NL0--SQynlQA:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id 425196455; Thu, 3 Mar 2011 00:03:03 -0800 (PST) Message-ID: <4D6F4B36.6010808@telus.net> Date: Thu, 03 Mar 2011 00:03:02 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6C78D3.5090803@telus.net> <201103010800.35666.jhb@freebsd.org> <4D6D50AC.701@telus.net> <201103011713.40140.jhb@freebsd.org> In-Reply-To: <201103011713.40140.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2011 12:22:15 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:03:11 -0000 On 2011-03-01 2:13 PM, John Baldwin wrote: >> On 2011-03-01 5:00 AM, John Baldwin wrote: >>>> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() >>>> declaration (because it isn't a driver). >>> >>> Yes, that would explain it. >> >> I can explicitly include ucom in a kernel by adding "device ucom" in the >> configuration file, in which case it would call DRIVER_MODULE(), right? >> That would then make it appear in the "kldstat -v" list? So why is it a >> driver when it's done explicitly, but not a driver when done implicitly? >> That makes no sense to me since the functionality doesn't change. IMHO, >> this is a bug that needs to be fixed, not just for ucom but any >> implicitly included driver. > > No, the _source_ code of device ucom has to explicitly say "I am a module > named 'foo'" using a DECLARE_MODULE() macro (or another macro such as > DRIVER_MODULE() that invokes DECLARE_MODULE()). The 'device ucom' in a config > file does not generate this, that is just an instruction that config(8) uses > when looking in sys/conf/files to see which C source files to include in the > kernel build. My wording was unclear. I do understand that it's the source code rather than the configuration file that invokes the macro. The argument I am making is that no matter how the ucom source code ends up being compiled into the kernel, the end result is that the ucom device is functionally present and available at run time. As such, it makes no sense to me that one can discover it's presence/availability with "kldstat -v" _only_ when compiled in as a consequence of a "device ucom" statement. As a user I care about accurate reporting when I query for information and currently "kldstat -v" cannot be relied upon. I shouldn't have to concern myself with what mechanism caused ucom to be included, but only that it was. Moreover, I suggest that for all practical purposes, a module is a module by virtue of its behaviour, not because DECLARE_MODULE() was invoked. Thus my assertion that this is a bug. Until it is fixed, please tell me how I can reliably query an existing kernel for a list of its functional modules/drivers. --Carl From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 12:53:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76FCC1065673 for ; Thu, 3 Mar 2011 12:53:01 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web120707.mail.ne1.yahoo.com (web120707.mail.ne1.yahoo.com [98.138.82.214]) by mx1.freebsd.org (Postfix) with SMTP id 1EDE68FC1B for ; Thu, 3 Mar 2011 12:53:00 +0000 (UTC) Received: (qmail 3541 invoked by uid 60001); 3 Mar 2011 12:53:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299156780; bh=W/DypWSBsJhf3kOOwp55RDebJSMur/mHygrog2HHVaQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=r7wUAOTL6/IzgDNN9dIIi8CHmwP2l9qG7NuWyu4HJY/h4GCm10EbxJoKQIS7780EnLItFIqOSP4/DLqTVFx42HL0rFoAR2wMP+zdVrJHX9sYwTwwPakovH4I5t+FYFaBQUE2di/tfQS5nX5H1KK7eff1kKja4yn9O02WXoCmHWw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=sRa+65ulHuMRHJdP9WpMwHRsmgipFr31c85gnDccG+DoWl6IoyRxtqE3wD1gmhmf1ULucP95lNdR1+lxoC4JbFK513ZLtoRueAVBS7Y055JJO92p6RCRU77ZU6s6EsXgMSRuJR0uxRFhwWvqCTXZOKXBTpASc2kXT8gUmKeZwE4=; Message-ID: <397755.98892.qm@web120707.mail.ne1.yahoo.com> X-YMail-OSG: nazVdccVM1n5WQPTNnkWI6_UyIB2TJEysHOt8oCjdIBjMaA eGrTYguwH21IFF65NXe9LHXorcpfv_OiInmCni.uKdkk9BtOWTes91tkEf0d YI0uPJAdlQoL8OBmpgTuOcy4vVQFp.XtTNj9kpfQ3d5YyeV_R9HYY6mw3ci4 DhvxtyFGD06EkzOZMVZwEB0QGvIE9dE7RP48eQI7e1ABDEgMSW.xEFTfnP9Y evuZHu.nva1wy5KBsmkCK7sYwgQ_e_tXKAMyuPoi92g4ZXlnnk.AFHx2siCa DeQ2J4YR51Me0iyyO Received: from [64.238.244.146] by web120707.mail.ne1.yahoo.com via HTTP; Thu, 03 Mar 2011 04:53:00 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 Date: Thu, 3 Mar 2011 04:53:00 -0800 (PST) From: "Dr. Baud" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 03 Mar 2011 13:17:18 +0000 Subject: vm.phys_free X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:53:01 -0000 Can someone explain exactly what phys_free is telling me, I understand the three pools (DEFAULT, DIRECT and CACHE) and 13 orders of pages. But what does lcnt represent? [root@sn12 ~]# sysctl vm.phys_free vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 12 | 0 | 6 11 ( 8192K) | 15 | 0 | 26 10 ( 4096K) | 39 | 0 | 38 9 ( 2048K) | 49 | 2 | 72 8 ( 1024K) | 29 | 1 | 137 7 ( 512K) | 41 | 1 | 231 6 ( 256K) | 74 | 0 | 332 5 ( 128K) | 127 | 1 | 448 4 ( 64K) | 149 | 4 | 725 3 ( 32K) | 278 | 13 | 980 2 ( 16K) | 388 | 36 | 1290 1 ( 8K) | 213 | 200 | 1831 0 ( 4K) | 0 | 627 | 2865 Dr. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 15:16:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68AA01065688 for ; Thu, 3 Mar 2011 15:16:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 24B148FC13 for ; Thu, 3 Mar 2011 15:16:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AF10446B03; Thu, 3 Mar 2011 10:16:42 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4AFB88A01B; Thu, 3 Mar 2011 10:16:42 -0500 (EST) From: John Baldwin To: Carl Date: Thu, 3 Mar 2011 10:08:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6C78D3.5090803@telus.net> <201103011713.40140.jhb@freebsd.org> <4D6F4B36.6010808@telus.net> In-Reply-To: <4D6F4B36.6010808@telus.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103031008.36250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 03 Mar 2011 10:16:42 -0500 (EST) Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:16:43 -0000 On Thursday, March 03, 2011 3:03:02 am Carl wrote: > On 2011-03-01 2:13 PM, John Baldwin wrote: > >> On 2011-03-01 5:00 AM, John Baldwin wrote: > >>>> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() > >>>> declaration (because it isn't a driver). > >>> > >>> Yes, that would explain it. > >> > >> I can explicitly include ucom in a kernel by adding "device ucom" in the > >> configuration file, in which case it would call DRIVER_MODULE(), right? > >> That would then make it appear in the "kldstat -v" list? So why is it a > >> driver when it's done explicitly, but not a driver when done implicitly? > >> That makes no sense to me since the functionality doesn't change. IMHO, > >> this is a bug that needs to be fixed, not just for ucom but any > >> implicitly included driver. > > > > No, the _source_ code of device ucom has to explicitly say "I am a module > > named 'foo'" using a DECLARE_MODULE() macro (or another macro such as > > DRIVER_MODULE() that invokes DECLARE_MODULE()). The 'device ucom' in a config > > file does not generate this, that is just an instruction that config(8) uses > > when looking in sys/conf/files to see which C source files to include in the > > kernel build. > > My wording was unclear. I do understand that it's the source code rather > than the configuration file that invokes the macro. The argument I am > making is that no matter how the ucom source code ends up being compiled > into the kernel, the end result is that the ucom device is functionally > present and available at run time. As such, it makes no sense to me that > one can discover it's presence/availability with "kldstat -v" _only_ > when compiled in as a consequence of a "device ucom" statement. As a > user I care about accurate reporting when I query for information and > currently "kldstat -v" cannot be relied upon. I shouldn't have to > concern myself with what mechanism caused ucom to be included, but only > that it was. Moreover, I suggest that for all practical purposes, a > module is a module by virtue of its behaviour, not because > DECLARE_MODULE() was invoked. Thus my assertion that this is a bug. Ah, but your assertion is what is wrong. There is no 'apic' module for 'device apic' for example. Also, a single 'device foo' might enable multiple "modules" (e.g. if foo supports devices on both PCI and ISA buses, you will have foo/pci and foo/isa modules). A module != a kld. A kld file may contain zero or more modules. Most kld's include at least one module. > Until it is fixed, please tell me how I can reliably query an existing > kernel for a list of its functional modules/drivers. There are ways to query multiple things about the kernel, but they are more specific than a nebulous "module" concept: - kldstat lists the kld's currently loaded - kldstat -v lists the declared modules in all of the kld's - lsvfs lists the filesystems currently available - all new-bus device drivers end up in the kldstat -v output as 'driver/parent', but this does not work for devices that are actually support libraries shared by other drivers (e.g. ucom). ucom is a bit special as it isn't an actual driver, it's a library of routines shared by various USB serial drivers: u3g, uark, ubsa, uftdi, etc. Those are the "real" drivers that one would want to test for. By itself 'device ucom' doesn't buy you anything. 'device ucom' is probably dubious as if you put 'device u3g' in your kernel config, the kernel will automatically include the USB serial driver library routines. If you 'kldload u3g.ko' it will automatically load 'ucom.ko' as a dependency, so an explicit 'device ucom' is generally not needed. There is no 'device uether' for the common USB ethernet routines shared by all the USB ethernet drivers (though there is a uether.ko), and 'device ucom' should probably be removed. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:09:38 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24BF106566C for ; Thu, 3 Mar 2011 18:09:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6428FC14 for ; Thu, 3 Mar 2011 18:09:36 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id p23HnmvP011858 for ; Thu, 3 Mar 2011 09:49:48 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id p23HnmKn011857 for hackers@freebsd.org; Thu, 3 Mar 2011 09:49:48 -0800 (PST) (envelope-from david) Date: Thu, 3 Mar 2011 09:49:48 -0800 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20110303174948.GF1471@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/aVve/J9H4Wl5yVO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:09:38 -0000 --/aVve/J9H4Wl5yVO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm using a little shell script to capture selected sysctl OID values periodically, in an attempt to get a better idea how the resources of a system are being used during a long-running (usually measured in hours), mission-critical workload. In the process of testing this, I've seen some of the VFS sysctl OIDs (in particular) report negative values ... when the description looks to me as if the OID in question is intended to be a monotonically increasing counter. For example: > sysctl -d vfs.getnewbufcalls vfs.getnewbufcalls: Number of calls to getnewbuf > sysctl vfs.getnewbufcalls vfs.getnewbufcalls: -348909432 Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls appears to be: =2E.. static int getnewbufcalls; SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0, "Number of calls to getnewbuf"); =2E.. Many of the other OIDs defined nearby are also SYSCTL_INT (or SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding variables are defined as static int (or static long) vs. static u_int (or static u_long). Is this both correct and reasonable? If so, how should I interpret such negative values? [GSoC project, anyone?] Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/aVve/J9H4Wl5yVO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk1v1LsACgkQmprOCmdXAD2RzgCfWovvxO4dXSqZWHB/4fgrZtap eMMAn0wbVs9/iNC0yepAiO5zSXYfG3zP =ttJq -----END PGP SIGNATURE----- --/aVve/J9H4Wl5yVO-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:37:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002B9106566B for ; Thu, 3 Mar 2011 17:37:26 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound04.telus.net [199.185.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id A6B298FC12 for ; Thu, 3 Mar 2011 17:37:26 +0000 (UTC) Received: from edtncm04 ([199.185.220.240]) by priv-edtnes24.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110303173725.PVHA18968.priv-edtnes24.telusplanet.net@edtncm04> for ; Thu, 3 Mar 2011 10:37:25 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edtncm04 with bizsmtp id EhdQ1g00k3VzCbE01hdQ3w; Thu, 03 Mar 2011 10:37:25 -0700 X-Telus-Outbound-IP: 66.183.53.162 X-Authority-Analysis: v=1.1 cv=Hhb8vUndaQ9JqXo/Swdf63bQvjw2wPrzWawgI51+Yeo= c=1 sm=2 a=ZLM83dXrbFwA:10 a=8nJEP1OIZ-IA:10 a=0KaIw0TcgJitHo1wxPkA:9 a=K4nJAcBs16x5mvLyh-gA:7 a=Y38DdXB3A-cePQTD6_EelwXR_z0A:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id CC0256455; Thu, 3 Mar 2011 09:37:23 -0800 (PST) Message-ID: <4D6FD1D2.1060404@telus.net> Date: Thu, 03 Mar 2011 09:37:22 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6C78D3.5090803@telus.net> <201103011713.40140.jhb@freebsd.org> <4D6F4B36.6010808@telus.net> <201103031008.36250.jhb@freebsd.org> In-Reply-To: <201103031008.36250.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2011 19:08:13 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:37:27 -0000 On 2011-03-03 7:08 AM, John Baldwin wrote: > Ah, but your assertion is what is wrong. There is no 'apic' module for > 'device apic' for example. Also, a single 'device foo' might enable > multiple "modules" (e.g. if foo supports devices on both PCI and ISA > buses, you will have foo/pci and foo/isa modules). > > A module != a kld. A kld file may contain zero or more modules. Most kld's > include at least one module. > >> Until it is fixed, please tell me how I can reliably query an existing >> kernel for a list of its functional modules/drivers. > > There are ways to query multiple things about the kernel, but they are more > specific than a nebulous "module" concept: > > - kldstat lists the kld's currently loaded > - kldstat -v lists the declared modules in all of the kld's > - lsvfs lists the filesystems currently available > - all new-bus device drivers end up in the kldstat -v output as > 'driver/parent', but this does not work for devices that are actually > support libraries shared by other drivers (e.g. ucom). > > ucom is a bit special as it isn't an actual driver, it's a library of routines > shared by various USB serial drivers: u3g, uark, ubsa, uftdi, etc. Those are > the "real" drivers that one would want to test for. By itself 'device ucom' > doesn't buy you anything. 'device ucom' is probably dubious as if you put > 'device u3g' in your kernel config, the kernel will automatically include the > USB serial driver library routines. If you 'kldload u3g.ko' it will > automatically load 'ucom.ko' as a dependency, so an explicit 'device ucom' is > generally not needed. There is no 'device uether' for the common USB ethernet > routines shared by all the USB ethernet drivers (though there is a uether.ko), > and 'device ucom' should probably be removed. Thanks for the great explanation, John. What prompted this thread was me wanting to know which *.ko files corresponded to functionality already included in the kernel. And ucom became a point of focus, in part, because no less than 13 different man pages specify that "device ucom" is required in the configuration file despite the fact that the GENERIC kernel has no such statement and contains ucom. Since the man pages are therefore in error, I've already provided HPS with a patch that perhaps he will use to correct the man pages. --Carl From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:25:25 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD73106564A for ; Thu, 3 Mar 2011 21:25:25 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 729F18FC08 for ; Thu, 3 Mar 2011 21:25:25 +0000 (UTC) Received: by wyb32 with SMTP id 32so1748778wyb.13 for ; Thu, 03 Mar 2011 13:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n0BJFGndIeERCyOrcFomQdaa44YY2c/79dopjwxAs70=; b=Vo7ss05+AsnNm3EMGeVujmkIm9B/OrPnOyaY2iUqPJctwUuqY6gpy4m5syi4XCFvn2 sl67UaYeoQdvF8tnGCp6rPE2vDTDV0sE6/VuGB7dmAmyFpS6SSts7dYBr/fq4adHzjGx FHiOrPujDx4cgCIQVTjWAVsQg0VaeibJW2O9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P9ci+bOxQEHuM9FzA20ppxpW01679z8QJbtHwlcsYH+orcMjNAFJWXQ36Gyj+7ZNH/ Mm3qTI4KqvWwfWN9r+AstkXJ8kRkghvqnYhfRKsqfDPU88wpVivE2P5kDnBkOnHkFAEo 6TnSUT7YxU98l4u6o/hFPV0dRz8CSvaDZVMkg= MIME-Version: 1.0 Received: by 10.216.141.16 with SMTP id f16mr1254608wej.80.1299186182456; Thu, 03 Mar 2011 13:03:02 -0800 (PST) Received: by 10.216.25.72 with HTTP; Thu, 3 Mar 2011 13:03:02 -0800 (PST) In-Reply-To: <20110303174948.GF1471@albert.catwhisker.org> References: <20110303174948.GF1471@albert.catwhisker.org> Date: Thu, 3 Mar 2011 15:03:02 -0600 Message-ID: From: Brandon Gooch To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:25:25 -0000 On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill wro= te: > I'm using a little shell script to capture selected sysctl OID > values periodically, in an attempt to get a better idea how the > resources of a system are being used during a long-running (usually > measured in hours), mission-critical workload. > > In the process of testing this, I've seen some of the VFS sysctl > OIDs (in particular) report negative values ... when the description > looks to me as if the OID in question is intended to be a monotonically > increasing counter. > > For example: > >> sysctl -d vfs.getnewbufcalls > vfs.getnewbufcalls: Number of calls to getnewbuf >> sysctl vfs.getnewbufcalls > vfs.getnewbufcalls: -348909432 > > Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls > appears to be: > > ... > static int getnewbufcalls; > SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0= , > =A0 "Number of calls to getnewbuf"); > ... > > Many of the other OIDs defined nearby are also SYSCTL_INT (or > SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding > variables are defined as static int (or static long) vs. static u_int > (or static u_long). > > Is this both correct and reasonable? =A0If so, how should I interpret suc= h > negative values? > > [GSoC project, anyone?] > > Thanks! > > Peace, > david The following initiative may factor heavily into any decision to change sysctl declarations at this point: http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Type-= Safety I don't pretend to fully understand the reasons or impact of this project, but I have to imagine that at least the scope is similar to a proposed GSoC project (probably bigger). -Brandon From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:57:28 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42761106566C for ; Thu, 3 Mar 2011 21:57:28 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA4898FC0C for ; Thu, 3 Mar 2011 21:57:27 +0000 (UTC) Received: by wyb32 with SMTP id 32so1780807wyb.13 for ; Thu, 03 Mar 2011 13:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j6OOp6DNH6sFMdolfvxm3giP11cDSC2vE3Y8EsE99jA=; b=LL9s0Ha8bbG9oAHD96YRMSvaFc0iOG8f4GRokeowqlZWSgbn9QobHSY/nthg7STOTI pwyyECuY2kln6fgfqdHgfZOunhjciDySW8uLWh4nbEsltO0OwCwpEXU7imGeCAwnraRe K4Ls7mgtciuNtrIz8cJjXsc+1/Nif0zf7IBJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qpJCUR2dP0LBhuCdddzoIXPhl0ETgUvNbXTCOjmhi3p443m2GQbr4BpdUGKO9jZctP EhUOoNaGwqXiji9MjK4t/G0UOGf26iCLEqYC/XlObFL/pcerLZzuSwpunb3UI4gaZ9E9 zjL8p9uncTeMDVY9iAbUA8jiIXBub4IdAyF3Y= MIME-Version: 1.0 Received: by 10.216.156.6 with SMTP id l6mr1068763wek.55.1299188085513; Thu, 03 Mar 2011 13:34:45 -0800 (PST) Received: by 10.216.72.147 with HTTP; Thu, 3 Mar 2011 13:34:45 -0800 (PST) In-Reply-To: References: <20110303174948.GF1471@albert.catwhisker.org> Date: Thu, 3 Mar 2011 13:34:45 -0800 Message-ID: From: Matthew Fleming To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:57:28 -0000 On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch wrote: > On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill w= rote: >> I'm using a little shell script to capture selected sysctl OID >> values periodically, in an attempt to get a better idea how the >> resources of a system are being used during a long-running (usually >> measured in hours), mission-critical workload. >> >> In the process of testing this, I've seen some of the VFS sysctl >> OIDs (in particular) report negative values ... when the description >> looks to me as if the OID in question is intended to be a monotonically >> increasing counter. >> >> For example: >> >>> sysctl -d vfs.getnewbufcalls >> vfs.getnewbufcalls: Number of calls to getnewbuf >>> sysctl vfs.getnewbufcalls >> vfs.getnewbufcalls: -348909432 >> >> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >> appears to be: >> >> ... >> static int getnewbufcalls; >> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, = 0, >> =A0 "Number of calls to getnewbuf"); >> ... >> >> Many of the other OIDs defined nearby are also SYSCTL_INT (or >> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >> variables are defined as static int (or static long) vs. static u_int >> (or static u_long). >> >> Is this both correct and reasonable? =A0If so, how should I interpret su= ch >> negative values? >> >> [GSoC project, anyone?] >> >> Thanks! >> >> Peace, >> david > > The following initiative may factor heavily into any decision to > change sysctl declarations at this point: > > http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Typ= e-Safety The intent of the type-safety is to make sure that the types assumed for the kernel's sysctl handler match the type of the variable. This project won't fix issues where a signed type is being used and the value wraps (at least, I presume that's what happened in this case?) Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:03:11 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23104106566C for ; Thu, 3 Mar 2011 22:03:11 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A853A8FC18 for ; Thu, 3 Mar 2011 22:03:10 +0000 (UTC) Received: by wyb32 with SMTP id 32so1786169wyb.13 for ; Thu, 03 Mar 2011 14:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=23X58G1/Z/L88uGOguuqrYqyhS8neb2JjN4cw8ljWJE=; b=S5Jc2rAhTvWFeZHpf/mGtQbQo3rTNjxuuf8bSu7oIuD1mPAulZR5Ci6STLsQ8DEFOa OySEXnOR5tV4y57BN9a2R8aqetprJMJS+F9XJSklySI/uePBS0Y8FVFUKA0g8gwcnHH3 /NbQuEXMNN9q/aRyAgpf75d6nv5qmco5AkHN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TvdPQubLDRbEcvtwd9CulF++x3Kdros15m8Q4bK+CNYoFCFkGHdKYO6+WeVP5k7Zjx JbZoq2YT66Xbf1Y5NpdG9PnzQiQOmGkY79BR1sTcNAwMga4iCUDWTY1egb0j4MLUIELC smCBcSYjsNqK+lFJs7+gTcVJJKPOZRnawfaR0= MIME-Version: 1.0 Received: by 10.216.167.13 with SMTP id h13mr1281246wel.95.1299189789604; Thu, 03 Mar 2011 14:03:09 -0800 (PST) Received: by 10.216.25.72 with HTTP; Thu, 3 Mar 2011 14:03:09 -0800 (PST) In-Reply-To: References: <20110303174948.GF1471@albert.catwhisker.org> Date: Thu, 3 Mar 2011 16:03:09 -0600 Message-ID: From: Brandon Gooch To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:03:11 -0000 On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming wrote: > On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch > wrote: >> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill = wrote: >>> I'm using a little shell script to capture selected sysctl OID >>> values periodically, in an attempt to get a better idea how the >>> resources of a system are being used during a long-running (usually >>> measured in hours), mission-critical workload. >>> >>> In the process of testing this, I've seen some of the VFS sysctl >>> OIDs (in particular) report negative values ... when the description >>> looks to me as if the OID in question is intended to be a monotonically >>> increasing counter. >>> >>> For example: >>> >>>> sysctl -d vfs.getnewbufcalls >>> vfs.getnewbufcalls: Number of calls to getnewbuf >>>> sysctl vfs.getnewbufcalls >>> vfs.getnewbufcalls: -348909432 >>> >>> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >>> appears to be: >>> >>> ... >>> static int getnewbufcalls; >>> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls,= 0, >>> =A0 "Number of calls to getnewbuf"); >>> ... >>> >>> Many of the other OIDs defined nearby are also SYSCTL_INT (or >>> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >>> variables are defined as static int (or static long) vs. static u_int >>> (or static u_long). >>> >>> Is this both correct and reasonable? =A0If so, how should I interpret s= uch >>> negative values? >>> >>> [GSoC project, anyone?] >>> >>> Thanks! >>> >>> Peace, >>> david >> >> The following initiative may factor heavily into any decision to >> change sysctl declarations at this point: >> >> http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Ty= pe-Safety > > The intent of the type-safety is to make sure that the types assumed > for the kernel's sysctl handler match the type of the variable. =A0This > project won't fix issues where a signed type is being used and the > value wraps (at least, I presume that's what happened in this case?) > > Thanks, > matthew Yes, it's wrapping. I wonder, would an audit of the SYCTL_* types be of general use to FreeBSD? I haven't ran into these issues myself, but I can see where this could become more of a problem with the OS in general as larger, heavier loads are placed on general-purpose type systems; where FreeBSD has been used in a product, I assume that the companies engineers, such as those at Isilon, have applied local patches where necessary. Y'know, I think this could be a good GSoC project after all... -Brandon From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:12:55 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5415106568E for ; Thu, 3 Mar 2011 22:12:55 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0B25A8FC1A for ; Thu, 3 Mar 2011 22:12:54 +0000 (UTC) Received: by wwb31 with SMTP id 31so2095398wwb.31 for ; Thu, 03 Mar 2011 14:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xAxBLDyK6kmfL7+cNijwMSowwvpFXu42ODcqqwvwCv8=; b=CtgHhiaqn4UICGErtSCNVZ4842XKqq+UPCrlnGydR5N43TkJfrTrm21BTBRLdLbZO/ AI8vc9LyGJSgvpF+dVoM06i4HPycyYHZ1xdMV3PURF176STVdZpzifeRud59cr6WVCls 2pQBe+Z8gY2hF8rjTatDyaIjx3Vvdo4ZuqYvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BwI+Fb/QV2jROH7BvficHqQICTeMbfyoKUSLZkX4mK7dp4gnqu5n9vGo+9yyhJsrMU e4UzKUx0kxRf/JSc1ySun0+41ApIAx23ZEbHWdg1pCVCfDEX9B2bGWj30VSP4v5jDmIZ kb5UqLwwNGJ5y11k8IlOWg35+Usa7lQZfLDc4= MIME-Version: 1.0 Received: by 10.216.48.70 with SMTP id u48mr1398833web.25.1299190373031; Thu, 03 Mar 2011 14:12:53 -0800 (PST) Received: by 10.216.72.147 with HTTP; Thu, 3 Mar 2011 14:12:52 -0800 (PST) In-Reply-To: References: <20110303174948.GF1471@albert.catwhisker.org> Date: Thu, 3 Mar 2011 14:12:52 -0800 Message-ID: From: Matthew Fleming To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:12:55 -0000 On Thu, Mar 3, 2011 at 2:03 PM, Brandon Gooch wrote: > On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming wrote: >> On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch >> wrote: >>> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill = wrote: >>>> I'm using a little shell script to capture selected sysctl OID >>>> values periodically, in an attempt to get a better idea how the >>>> resources of a system are being used during a long-running (usually >>>> measured in hours), mission-critical workload. >>>> >>>> In the process of testing this, I've seen some of the VFS sysctl >>>> OIDs (in particular) report negative values ... when the description >>>> looks to me as if the OID in question is intended to be a monotonicall= y >>>> increasing counter. >>>> >>>> For example: >>>> >>>>> sysctl -d vfs.getnewbufcalls >>>> vfs.getnewbufcalls: Number of calls to getnewbuf >>>>> sysctl vfs.getnewbufcalls >>>> vfs.getnewbufcalls: -348909432 >>>> >>>> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >>>> appears to be: >>>> >>>> ... >>>> static int getnewbufcalls; >>>> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls= , 0, >>>> =A0 "Number of calls to getnewbuf"); >>>> ... >>>> >>>> Many of the other OIDs defined nearby are also SYSCTL_INT (or >>>> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >>>> variables are defined as static int (or static long) vs. static u_int >>>> (or static u_long). >>>> >>>> Is this both correct and reasonable? =A0If so, how should I interpret = such >>>> negative values? >>>> >>>> [GSoC project, anyone?] >>>> >>>> Thanks! >>>> >>>> Peace, >>>> david >>> >>> The following initiative may factor heavily into any decision to >>> change sysctl declarations at this point: >>> >>> http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-T= ype-Safety >> >> The intent of the type-safety is to make sure that the types assumed >> for the kernel's sysctl handler match the type of the variable. =A0This >> project won't fix issues where a signed type is being used and the >> value wraps (at least, I presume that's what happened in this case?) >> >> Thanks, >> matthew > > Yes, it's wrapping. I wonder, would an audit of the SYCTL_* types be > of general use to FreeBSD? I haven't ran into these issues myself, but > I can see where this could become more of a problem with the OS in > general as larger, heavier loads are placed on general-purpose type > systems; where FreeBSD has been used in a product, I assume that the > companies engineers, such as those at Isilon, have applied local > patches where necessary. Y'know, I think this could be a good GSoC > project after all... Yes and no. :-) The problem with changing the types is that it can be an ABI change. See the function sysctl_bufspace() in vfs_bio.c which stands on its head to output an int size if that's what the caller expects. This problem is mitigated (or made worse, depending on your POV) by a commit I plan to make when $WORK is slightly less insane, to add a new sysctl handler that will copy out 4 bytes if that's what the caller expects and there's no overflow, or even perhaps if there is, even if the kernel type is 8 bytes. The upside of this new handler is that, like bufspace, it preserves ABI for applications that thought they knew the size. The downside is that (1) there's lots of design options, like copying out 4 bytes even if this truncates the data versus reporting the error, and (2) such a change means that broken applications don't know they're broken, if the FreeBSD type changes. I hope this explains the issues. All that said, personally I'm in favor of having the kernel have the right types, and fixing broken apps as they're found. This isn't the most friendly stance for third-party vendors, though. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 14:36:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F37106566B for ; Fri, 4 Mar 2011 14:36:43 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23A6A8FC15 for ; Fri, 4 Mar 2011 14:36:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so2265128iwn.13 for ; Fri, 04 Mar 2011 06:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=H4rqihW7a+WK3sXtrdviNwZkGRSTPVhwOqrh56elEvs=; b=bRL/9CNA/kymGVx1p07J68UDiDIEqe+hVgY6lDwShU2t9rbDrGBrJAKvS7K18sn56m VLmsq5Z+naIg7ZCOPV83pkK2HyGHchKJEmHLroLQP3uFRk1+FBk3hkKF4Q2NBquofz1g YkuWWYGlDXsFdVsoq5OGBUgXSt1W63Ogvht40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vIxLt9A85BOUSDIk9JbK+yxQ53Y30Q9zDUFoNWtdm/lkwcISx690m2al8rBBasXNLJ Zvyv2+IbynsUA10HtkhcucAhkkKHtNJIP47CiwW5ekAKksYBdunf7lhM+S1EhY5zSFO7 nVS3bzw3m5npFPSWlNnBhHDy8go775lcJqkO0= MIME-Version: 1.0 Received: by 10.42.159.6 with SMTP id j6mr689256icx.260.1299249402394; Fri, 04 Mar 2011 06:36:42 -0800 (PST) Received: by 10.231.144.140 with HTTP; Fri, 4 Mar 2011 06:36:42 -0800 (PST) Date: Fri, 4 Mar 2011 17:36:42 +0300 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: hw.physmem (loader.conf and sysctl) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:36:43 -0000 Hello Hackers, I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding the following in loader.conf: $ cat /boot/loader.conf | grep hw.physmem hw.physmem="500M" $ However, according to sysctl, the system sees $ sysctl hw.physmem hw.physmem: 507445248 $ The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. How does the system use this "hidden" memory? Thanks! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 17:48:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513401065670 for ; Fri, 4 Mar 2011 17:48:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9E91C8FC12 for ; Fri, 4 Mar 2011 17:48:58 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA02117; Fri, 04 Mar 2011 19:48:55 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D712607.3090106@freebsd.org> Date: Fri, 04 Mar 2011 19:48:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101213 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dmitry Krivenok References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: hw.physmem (loader.conf and sysctl) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:48:59 -0000 on 04/03/2011 16:36 Dmitry Krivenok said the following: > Hello Hackers, > I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding > the following in loader.conf: > > $ cat /boot/loader.conf | grep hw.physmem > hw.physmem="500M" > $ > > However, according to sysctl, the system sees > > $ sysctl hw.physmem > hw.physmem: 507445248 > $ > > The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. > How does the system use this "hidden" memory? Some memory is taken by structures that describe usable pages. There is one vm_page_t structure per each 4KB page. I believe that that memory is excluded from physmem. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:17:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5CAA106564A; Fri, 4 Mar 2011 19:17:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B8D4B8FC14; Fri, 4 Mar 2011 19:17:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4C66746B23; Fri, 4 Mar 2011 14:17:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DF1B78A01B; Fri, 4 Mar 2011 14:17:45 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 4 Mar 2011 14:17:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D712607.3090106@freebsd.org> In-Reply-To: <4D712607.3090106@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103041417.44584.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 04 Mar 2011 14:17:46 -0500 (EST) Cc: Dmitry Krivenok , Andriy Gapon Subject: Re: hw.physmem (loader.conf and sysctl) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:17:47 -0000 On Friday, March 04, 2011 12:48:55 pm Andriy Gapon wrote: > on 04/03/2011 16:36 Dmitry Krivenok said the following: > > Hello Hackers, > > I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding > > the following in loader.conf: > > > > $ cat /boot/loader.conf | grep hw.physmem > > hw.physmem="500M" > > $ > > > > However, according to sysctl, the system sees > > > > $ sysctl hw.physmem > > hw.physmem: 507445248 > > $ > > > > The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. > > How does the system use this "hidden" memory? > > Some memory is taken by structures that describe usable pages. > There is one vm_page_t structure per each 4KB page. > I believe that that memory is excluded from physmem. Also, the message buffer for dmesg, and the kernel binary itself. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:37:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D2A0106566B; Fri, 4 Mar 2011 19:37:30 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B0FC58FC13; Fri, 4 Mar 2011 19:37:29 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p24JCI8l023777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 20:12:19 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p24JC6o7096080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2011 20:12:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p24JC6WR038172; Fri, 4 Mar 2011 20:12:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p24JC6gh038171; Fri, 4 Mar 2011 20:12:06 +0100 (CET) (envelope-from ticso) Date: Fri, 4 Mar 2011 20:12:06 +0100 From: Bernd Walter To: Andriy Gapon Message-ID: <20110304191205.GO86812@cicely7.cicely.de> References: <4D712607.3090106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D712607.3090106@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Dmitry Krivenok Subject: Re: hw.physmem (loader.conf and sysctl) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:37:30 -0000 On Fri, Mar 04, 2011 at 07:48:55PM +0200, Andriy Gapon wrote: > on 04/03/2011 16:36 Dmitry Krivenok said the following: > > Hello Hackers, > > I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding > > the following in loader.conf: > > > > $ cat /boot/loader.conf | grep hw.physmem > > hw.physmem="500M" > > $ > > > > However, according to sysctl, the system sees > > > > $ sysctl hw.physmem > > hw.physmem: 507445248 > > $ > > > > The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. > > How does the system use this "hidden" memory? > > Some memory is taken by structures that describe usable pages. > There is one vm_page_t structure per each 4KB page. > I believe that that memory is excluded from physmem. hw.physmen doesn't set the physucal memory - it sets the maximum physical address. But there are unuseable addresses used for IO - e.g. the 640k-1M range and board depended PCI io-ranges. I set hw.physmem="8704M" on my 8G system to reduce memory (last bytes are declared uncacheable by broken BIOS). -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:58:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D601065675 for ; Fri, 4 Mar 2011 23:58:23 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4178FC0A for ; Fri, 4 Mar 2011 23:58:23 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p24Nvvrd002011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Mar 2011 15:58:23 -0800 (PST) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 4 Mar 2011 15:58:23 -0800 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Sat, 05 Mar 2011 00:20:51 +0000 Subject: Hot-ICE '11 Program Now Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 23:58:23 -0000 You're invited to join us at the first Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Service (Hot-ICE '11), which will take place in Boston, MA, on March 29, 2011. Hot-ICE '11 will bring together researchers and practitioners working on network and service management in the Internet, cloud, and enterprise domains. The scope of Hot-ICE includes all aspects of network and service management. The program includes sessions on cloud and resource management, service management, network management, and datacenter networking. In addition, a mini-panel will close each session. Check out the full program at: http://www.usenix.org/events/hotice11/tech/ Hot-ICE evolved from earlier Internet Network Management (INM) workshops, which more recently combined with the Workshop on Research on Enterprise Networking (WREN). As such, Hot-ICE, while a new workshop, is serving an established community, but with a broader scope, in recognition of the evolving concerns of the community. Hot-ICE '11 will be co-located with the 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11), which will take place March 30-April 1, 2011. Find out more and register today at: http://www.usenix.org/hotice11/proga On behalf of the Hot-ICE Program Committee, Anees Shaikh, IBM Research Kobus Van der Merwe, AT&T Labs--Research Hot-ICE '11 Program Co-Chairs hotice11chairs@usenix.org ----------------------------------------------------------------------- Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE '11) March 29, 2011 Boston, MA, USA http://www.usenix.org/hotice11/proga Sponsored by USENIX ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 04:26:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED02106566B for ; Sat, 5 Mar 2011 04:26:14 +0000 (UTC) (envelope-from anderson@ttel.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 741298FC15 for ; Sat, 5 Mar 2011 04:26:14 +0000 (UTC) Received: by yxl31 with SMTP id 31so1138747yxl.13 for ; Fri, 04 Mar 2011 20:26:13 -0800 (PST) Received: by 10.236.191.39 with SMTP id f27mr682136yhn.47.1299297767856; Fri, 04 Mar 2011 20:02:47 -0800 (PST) Received: from [10.0.7.145] (r74-193-70-198.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.70.198]) by mx.google.com with ESMTPS id 8sm90973yhl.44.2011.03.04.20.02.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 20:02:47 -0800 (PST) From: Eric Anderson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 22:02:45 -0600 Message-Id: <40A52D4A-9397-4406-A7EC-E7CBBEFADD55@freebsd.org> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sat, 05 Mar 2011 04:46:47 +0000 Subject: Mem leak : malloc/free + pthreads = leakage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 04:26:14 -0000 Hi all, I have a moderately threaded userland program (all C) I am working on = (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using = standard malloc/free) badly. I am using pcap to capture packets and = process them. I have a handful of libs statically linked in (pcap is = one, the rest don't seem to matter - I can remove them and still see the = leak). =20 Does anyone know of issues regarding malloc/free on multithreaded = userland apps? =20 Sorry, I can't post the code.. Thanks! Eric From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 12:23:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BF2106566B for ; Sat, 5 Mar 2011 12:23:04 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B9F108FC12 for ; Sat, 5 Mar 2011 12:23:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=yYeZnqgBzNde1SiZ5NPTGZP9wYT/ic0xmfi5JjYyk+c=; b=AW3Q8/8j8f9xXkuTHKRlpdNSzBMXVQ1BUfLXKDdrNKG5hq+pgYI4XTjWjjtSwH2AriGBaceKImVZ813ilPJL0OZjwSesmeTYYSt6He8ckSffqxBe0GCEhsRG6uVw9imDhHnI6n+l++a7P0wvjWXg/3OVe99VChgXY80vSF/IdVUpXOqvSe2xC9RoMK7egHpd+FI+fvGRTdXtWzIV5Te+xBPGmEAamif811baiQ+R9fwnaeHdoQVG1/fRF1Cjgg3PWoMoSbFq8oF6NhYlMH/OYd4ETudeDzLaIb5/IhipSedrI7I/xdRktSyYTijqhbo+msAWT/m+JNu2qyl1UEa7ZQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1PvqVi-000FsS-IA; Sat, 05 Mar 2011 15:23:02 +0300 Date: Sat, 5 Mar 2011 15:23:00 +0300 From: Eygene Ryabinkin To: Eric Anderson Message-ID: References: <40A52D4A-9397-4406-A7EC-E7CBBEFADD55@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TXIPBuAs4GDcsx9K" Content-Disposition: inline In-Reply-To: <40A52D4A-9397-4406-A7EC-E7CBBEFADD55@freebsd.org> Sender: rea@codelabs.ru Cc: freebsd-hackers@freebsd.org Subject: Re: Mem leak : malloc/free + pthreads = leakage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 12:23:04 -0000 --TXIPBuAs4GDcsx9K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote: > I have a moderately threaded userland program (all C) I am working > on (using pthreads, freebsd 8.1 64bit). It seems to leak memory > (using standard malloc/free) badly. I am using pcap to capture > packets and process them. I have a handful of libs statically linked > in (pcap is one, the rest don't seem to matter - I can remove them > and still see the leak). =20 >=20 > Does anyone know of issues regarding malloc/free on multithreaded > userland apps? =20 I personally hadn't heard about them, but you can definitely run your program under Valgrind's memcheck tool -- it often does the good amount of work and detects many leaks. Valrgind is ported to FreeBSD, devel/valgrind. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --TXIPBuAs4GDcsx9K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk1yKyQACgkQFq+eroFS7Ps/IAD/S06+1lvXvjsNfSKWu/tn7lBr RMWyq0DqloGZzMoEew8A/j+oniP5m/tcyTLpYaHfm5oCT0VzugcHkgJ9SMw2oz5Q =kDT7 -----END PGP SIGNATURE----- --TXIPBuAs4GDcsx9K-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 17:01:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A071D106566B for ; Sat, 5 Mar 2011 17:01:22 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (wooster.rojer.pp.ru [80.68.242.188]) by mx1.freebsd.org (Postfix) with ESMTP id 52DAD8FC0A for ; Sat, 5 Mar 2011 17:01:22 +0000 (UTC) Received: from wooster.rojer.pp.ru (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP id C05691145A; Sat, 5 Mar 2011 19:45:11 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.3.1-rojer (2010-03-16) on wooster.rojer.pp.ru X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1-rojer X-Spam-Level: Received: from [192.168.10.20] (87-198-218-130.static.ptr.magnet.ie [87.198.218.130]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by wooster.rojer.pp.ru (Postfix) with ESMTPSA id B38401147E; Sat, 5 Mar 2011 19:45:07 +0300 (MSK) Message-ID: <4D726887.5080800@rojer.pp.ru> Date: Sat, 05 Mar 2011 16:44:55 +0000 From: Deomid Ryabkov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Anderson References: <40A52D4A-9397-4406-A7EC-E7CBBEFADD55@freebsd.org> In-Reply-To: <40A52D4A-9397-4406-A7EC-E7CBBEFADD55@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Mem leak : malloc/free + pthreads = leakage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 17:01:22 -0000 On 03/05/2011 04:02 AM, Eric Anderson wrote: > Hi all, > > I have a moderately threaded userland program (all C) I am working on (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard malloc/free) badly. as opposed to what? OpenBSD? Linux? Windows? why do you think your problem is specific to FreeBSD (as evidenced by your post to a FreeBSD-specific list) or is related to threaded programs? > I am using pcap to capture packets and process them. I have a handful of libs statically linked in (pcap is one, the rest don't seem to matter - I can remove them and still see the leak). > > Does anyone know of issues regarding malloc/free on multithreaded userland apps? hell yeah. it goes like this: you malloc() then forget to free() - boom, you have a memory leak. you're welcome. sarcasm aside, those questions still remain: why do you think os/libraries are the problem and not your code? you can't post all of it, ok, and we don't want all of it either. can you isolate a specific example of where valid usage of a library causes a leak? > Sorry, I can't post the code.. > > Thanks! > Eric > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Deomid "rojer" Ryabkov myself@rojer.pp.ru ICQ: 8025844