From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 00:01:17 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 185D9106566B for ; Sun, 5 Jun 2011 00:01:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id C125B8FC12 for ; Sun, 5 Jun 2011 00:01:16 +0000 (UTC) X-AuditID: 1209190c-b7c65ae00000117c-3a-4deac753a8ff Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 37.56.04476.357CAED4; Sat, 4 Jun 2011 20:01:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p5501FNV008816; Sat, 4 Jun 2011 20:01:15 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5501DPb018592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 Jun 2011 20:01:15 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p5501DqC004504; Sat, 4 Jun 2011 20:01:13 -0400 (EDT) Date: Sat, 4 Jun 2011 20:01:13 -0400 (EDT) From: Benjamin Kaduk To: Ali Mashtizadeh In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6noht8/JWvwatmLovtm/8xWlzd7e7A 5DHj03wWj52z7rIHMEVx2aSk5mSWpRbp2yVwZaw/+pS1YA1rxcFNDewNjEtZuhg5OSQETCRO /pjCDmGLSVy4t56ti5GLQ0hgH6NE977z7BDOekaJPetnQGX2M0l8mPuQDaRFSKBe4s2MS2Dt LAJaEh/nH2cCsdkEVCRmvtkIViMioC3x781ToBoODmYBQ4lzG/xBwsICxhKb1uwBK+EUcJRY 3fwIzOYVcJCYOusFK8R4B4mJl7eAXSoqoCOxev8UFogaQYmTM5+A2cwClhL/1v5incAoOAtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBYcopybOD8c1BpUOM AhyMSjy8dkmvfIVYE8uKK3MPMUpyMCmJ8r46BhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwlsn ApTjTUmsrEotyodJSXOwKInzzpBU9xUSSE8sSc1OTS1ILYLJynBwKEnwVoAMFSxKTU+tSMvM KUFIM3FwggznARq+BqSGt7ggMbc4Mx0if4pRUUqc9z1IQgAkkVGaB9cLSyOvGMWBXhHmXQtS xQNMQXDdr4AGMwENPu4ENrgkESEl1cBo/m1+xWUr7z+BX7ZNOvzD6HTNzuenFjTE2vSHr6pJ lrXe8scgd9LHbT/EtLzufTez/L3mdd6EiATZxq+h+dJTqo+bh4koqt890MB14e3u079lNpl0 sTXPVfp2KlV7z17+qhtPXl12uTm9Tb/OWLZkelHQR3VO/2Sznx0hzSrLmxftvuvZm92pxFKc kWioxVxUnAgA/pvqWP4CAAA= Cc: FreeBSD Hackers Subject: Re: Opening files from within geom filters 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, 05 Jun 2011 00:01:17 -0000 On Sat, 4 Jun 2011, Ali Mashtizadeh wrote: > Hi Folks, > > I'm working on a small geom filter where I need to open a file with > vn_open_cred, but this causes an assert because of a null pointer > because g_run_event proc structure has null pointer for the current > working directory. Hi Ali, In general, it is not recommended to open a file from within the kernel, due to a multitude of complications and difficulties. The old thread here: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020544.html may provide you with some other options to do what you're doing, and insight from a previous time when this sort of question came up. -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 01:23: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 6EEF6106566B for ; Sun, 5 Jun 2011 01:23:55 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 250748FC08 for ; Sun, 5 Jun 2011 01:23:54 +0000 (UTC) Received: by qyk27 with SMTP id 27so1725494qyk.13 for ; Sat, 04 Jun 2011 18:23:54 -0700 (PDT) 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; bh=MHWwU6sN8Wl/dSVALQSZ7o0Jtj0AKWGPk6flqZ/js6w=; b=EAW8w2/pSwPEwS/AFHCFbAkeLt/iVqPtiyGFG07QoVLNO098eBRGwLgmCTdE7vB6m2 L1AQfG9S81yrO4+AOHdctoPuRyr44Fc3gdVGnkBzHQv8PrSFTbAjmH03cM/lWtBSI/N9 gAnuZ9AdgT7HKv5LQoZDuUShF5y2Rr4+bAbtc= 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; b=sGbH16CJEKTjYDhFlja+B/G1VkofqrfxRZxV+fuSVfv5C1qDx+8GJ2v7em3EuTKKlt 8UahgFXmeLW+iuP2cHE4wxEMZlz5mbCBCABr4NkKGAICzGOO+Y+epbNVh/SUkBLZNli6 YPp1KXJw5744kroD1nE1ledBdW/7Mfgf1EFj0= MIME-Version: 1.0 Received: by 10.229.237.18 with SMTP id km18mr2493133qcb.126.1307237034190; Sat, 04 Jun 2011 18:23:54 -0700 (PDT) Received: by 10.229.10.10 with HTTP; Sat, 4 Jun 2011 18:23:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Jun 2011 01:23:54 +0000 Message-ID: From: Ali Mashtizadeh To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers Subject: Re: Opening files from within geom filters 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, 05 Jun 2011 01:23:55 -0000 Hi Benjamin, Thanks for the reference. I originally wanted to open an fd in userspace as suggested, but the alq(9) API did not support that. I guess I'll try adding a new alq creation function for this purpose. Similarly, geom did not support that as well. I guess I'll spend sometime on adding that infrastructure. Thanks, ~ Ali On Sun, Jun 5, 2011 at 12:01 AM, Benjamin Kaduk wrote: > On Sat, 4 Jun 2011, Ali Mashtizadeh wrote: > >> Hi Folks, >> >> I'm working on a small geom filter where I need to open a file with >> vn_open_cred, but this causes an assert because of a null pointer >> because g_run_event proc structure has null pointer for the current >> working directory. > > Hi Ali, > > In general, it is not recommended to open a file from within the kernel, due > to a multitude of complications and difficulties. > The old thread here: > http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020544.html > may provide you with some other options to do what you're doing, and insight > from a previous time when this sort of question came up. > > -Ben Kaduk > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 05:08:45 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 B43B8106566B for ; Sun, 5 Jun 2011 05:08:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 765C68FC15 for ; Sun, 5 Jun 2011 05:08:45 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5553AHP072271 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 4 Jun 2011 23:03:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DEA988C.5030003@links.org> Date: Sat, 4 Jun 2011 23:03:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <526C5DC0-F449-457D-8B25-8887BEFE869A@bsdimp.com> References: <4DEA988C.5030003@links.org> To: Ben Laurie X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 04 Jun 2011 23:03:10 -0600 (MDT) Cc: hackers@FreeBSD.org Subject: Re: _LP64 and _ILP32 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, 05 Jun 2011 05:08:45 -0000 I'd add them for all !_LP64 architectures: arm, mips o32, mips n32, = i386, and powerpc... Warner On Jun 4, 2011, at 2:41 PM, Ben Laurie wrote: > It turns out that both clang and gcc define _LP64 when used native on = amd64. >=20 > Neither defines _ILP32 on i386 (native or cross-compiled). >=20 > dt_popc() in cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c > needs on or the other. clang notices because when _ILP32 is missing > there's no return. >=20 > So ... thoughts?-- >=20 > http://www.apache-ssl.org/ben.html http://www.links.org/ >=20 > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff >=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" >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 06:21: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 504E5106564A for ; Sun, 5 Jun 2011 06:21:01 +0000 (UTC) (envelope-from buganini@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 19DDB8FC0A for ; Sun, 5 Jun 2011 06:21:00 +0000 (UTC) Received: by iwn33 with SMTP id 33so3664100iwn.13 for ; Sat, 04 Jun 2011 23:21:00 -0700 (PDT) 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:cc:content-type; bh=Wo1WR2FG1cfZOw8ZrgqpRjV9uWxR5oxVY3/+uYuUujA=; b=rJBF04D2ErMQZ30DMbaXHAUAPm5B19WipzO+MrOwx6qyGB/GzFPenZbOLWrJpBwcce jO3FvrnN8hiKYL0yzjgnWJn1VgNyThfQGnv67yiaTZz2rp0BGi3FZ/TDGeBP48b4oAm/ tfjEbPN0YltFwckq76pFI2oMf25gJ52dy1b3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=eSjfCNtd6GMSzDRt30f48opuK9e+9sAtidT/EOYQ9NuHO/3uABBVeUWiWuRN8Pnxta dQSo1S85PfhtJtni7fP+QRd9gmiUVHU4xIrKsbV2UXQFYlwEV5m/B11SSnlj/ZlCt/nN NZdUFDLxX/nsJapSefEsDkmBkJoeVFLfV5oLM= MIME-Version: 1.0 Received: by 10.231.129.13 with SMTP id m13mt7187799ibs.75.1307254860467; Sat, 04 Jun 2011 23:21:00 -0700 (PDT) Received: by 10.231.35.75 with HTTP; Sat, 4 Jun 2011 23:21:00 -0700 (PDT) In-Reply-To: <20110604122703.GB33796@stack.nl> References: <20110604122703.GB33796@stack.nl> Date: Sun, 5 Jun 2011 14:21:00 +0800 Message-ID: From: Buganini Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Jilles Tjoelker , Julien Laffaye Subject: Re: [RFC] rcexecr: rcorder in parallel 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, 05 Jun 2011 06:21:01 -0000 All functional parts are done (unless I forgot something..) patch for /etc is included (against CURRENT), and tested on my laptop. In my case, with rcexecr and the patch, the time for launching rc.d scripts reduces from 35s to 26s. manpage is updated, but I think my English needs some fix :p Regards, Buganini From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 10:05: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 824FA1065670; Sun, 5 Jun 2011 10:05:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6828FC08; Sun, 5 Jun 2011 10:05:48 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0B7E046B24; Sun, 5 Jun 2011 06:05:48 -0400 (EDT) Date: Sun, 5 Jun 2011 11:05:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: mdf@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers , Bruce Evans Subject: Re: sizeof(function pointer) 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, 05 Jun 2011 10:05:48 -0000 On Tue, 31 May 2011, mdf@FreeBSD.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds drains > to sbufs. The reason for MFC is that several pieces of new code in CURRENT > are using the drain functionality and it would make MFCing those changes > much easier. > > The problem is that r212367 added a pointer to a drain function in the sbuf > (it replaced a pointer to void). The C standard doesn't guarantee that a > void * and a function pointer have the same size, though its true on amd64, > i386 and I believe PPC. What I'm wondering is, though not guaranteed by the > standard, is it *practically* true that sizeof(void *) == > sizeof(int(*)(void)), such that an MFC won't break binary compatibility for > any supported architecture? (The standard does guarantee, though not in > words, that all function pointers have the same size, since it guarantees > that pointers to functions can be cast to other pointers to functions and > back without changing the value). I think you're OK for MFC purposes, but that in general, we shouldn't assume that they are the same size. I.e., we should use a function pointer type where we mean a function pointer type, and never write code that casts a function pointer to a regular pointer. (Which the change is fine with respect to, I believe). I'm doing some research on an experimental architecture where certain types of function pointers are 256-bit. This has some interesting consequences; we haven't yet gotten to investigating C language extensions/compatibility, but that will follow in the next year or so. (We also have 256-bit data references, similar to pointers, for use in some environments, which will also prove interesting. I'm not yet convinced we'll try to use a general pointer type for them, but perhaps instead extend the language to have a qualified type of some sort). Robert From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 10:13:00 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 D3DBE106564A for ; Sun, 5 Jun 2011 10:13:00 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB9B8FC0C for ; Sun, 5 Jun 2011 10:13:00 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 8B08F33C1A; Sun, 5 Jun 2011 11:12:59 +0100 (BST) Message-ID: <4DEB56B1.2040309@links.org> Date: Sun, 05 Jun 2011 11:13:05 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4DEA988C.5030003@links.org> <526C5DC0-F449-457D-8B25-8887BEFE869A@bsdimp.com> In-Reply-To: <526C5DC0-F449-457D-8B25-8887BEFE869A@bsdimp.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Jun 2011 11:38:01 +0000 Cc: hackers@FreeBSD.org Subject: Re: _LP64 and _ILP32 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, 05 Jun 2011 10:13:00 -0000 On 05/06/2011 06:03, Warner Losh wrote: > I'd add them for all !_LP64 architectures: arm, mips o32, mips n32, i386, and powerpc... Forgive the stupid question, but ... add them to what? > > Warner > > On Jun 4, 2011, at 2:41 PM, Ben Laurie wrote: > >> It turns out that both clang and gcc define _LP64 when used native on amd64. >> >> Neither defines _ILP32 on i386 (native or cross-compiled). >> >> dt_popc() in cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c >> needs on or the other. clang notices because when _ILP32 is missing >> there's no return. >> >> So ... thoughts?-- >> >> http://www.apache-ssl.org/ben.html http://www.links.org/ >> >> "There is no limit to what a man can do or how far he can go if he >> doesn't mind who gets the credit." - Robert Woodruff >> >> _______________________________________________ >> 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" >> >> > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 17:17:59 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 9A3CE106566C for ; Sun, 5 Jun 2011 17:17:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 539958FC13 for ; Sun, 5 Jun 2011 17:17:59 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p55HDFfE077139 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 5 Jun 2011 11:13:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4DEB56B1.2040309@links.org> Date: Sun, 5 Jun 2011 11:13:12 -0600 Message-Id: <3653FDA9-7CBE-4217-BDE9-78E2970E89F1@bsdimp.com> References: <4DEA988C.5030003@links.org> <526C5DC0-F449-457D-8B25-8887BEFE869A@bsdimp.com> <4DEB56B1.2040309@links.org> To: Ben Laurie X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 05 Jun 2011 11:13:16 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: _LP64 and _ILP32 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, 05 Jun 2011 17:17:59 -0000 On Jun 5, 2011, at 4:13 AM, Ben Laurie wrote: > On 05/06/2011 06:03, Warner Losh wrote: >> I'd add them for all !_LP64 architectures: arm, mips o32, mips n32, = i386, and powerpc... >=20 > Forgive the stupid question, but ... add them to what? If they aren't already defined by the compilers, those compilers should = be modified to define them. I thought they were defined already, it = appears not. Warner >> Warner >>=20 >> On Jun 4, 2011, at 2:41 PM, Ben Laurie wrote: >>=20 >>> It turns out that both clang and gcc define _LP64 when used native = on amd64. >>>=20 >>> Neither defines _ILP32 on i386 (native or cross-compiled). >>>=20 >>> dt_popc() in cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c >>> needs on or the other. clang notices because when _ILP32 is missing >>> there's no return. >>>=20 >>> So ... thoughts?-- >>>=20 >>> http://www.apache-ssl.org/ben.html http://www.links.org/ >>>=20 >>> "There is no limit to what a man can do or how far he can go if he >>> doesn't mind who gets the credit." - Robert Woodruff >>>=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" >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > http://www.apache-ssl.org/ben.html http://www.links.org/ >=20 > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 18:13:16 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 BA4F5106564A for ; Sun, 5 Jun 2011 18:13:16 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9188FC12 for ; Sun, 5 Jun 2011 18:13:16 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 1DA0E33C1C for ; Sun, 5 Jun 2011 19:13:15 +0100 (BST) Message-ID: <4DEBC741.1020200@links.org> Date: Sun, 05 Jun 2011 19:13:21 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: int64_t and printf 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, 05 Jun 2011 18:13:16 -0000 So, for example int64_t has no printf modifier I am aware of. Likewise its many friends. In the past I've handled this by having a define somewhere along the lines of... #if # define INT_64_T_FMT "%ld" #else # define INT_64_T_FMT "%lld" #endif but I have no idea where to put such a thing in FreeBSD. Opinions? Also, I guess I'd really need to do a modifier rather than a format, for full generality. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 18:31:29 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 E7EE91065672 for ; Sun, 5 Jun 2011 18:31:29 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f11:66f:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 929568FC12 for ; Sun, 5 Jun 2011 18:31:29 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f11:66f:1::5]) by mail.farley.org (8.14.5/8.14.5) with ESMTP id p55IVSI3022534; Sun, 5 Jun 2011 14:31:28 -0400 (EDT) (envelope-from scf@FreeBSD.org) Date: Sun, 5 Jun 2011 14:31:27 -0400 (EDT) From: "Sean C. Farley" To: Ben Laurie In-Reply-To: <4DEBC741.1020200@links.org> Message-ID: References: <4DEBC741.1020200@links.org> User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: hackers@FreeBSD.org Subject: Re: int64_t and printf 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, 05 Jun 2011 18:31:30 -0000 On Sun, 5 Jun 2011, Ben Laurie wrote: > So, for example int64_t has no printf modifier I am aware of. Likewise > its many friends. > > In the past I've handled this by having a define somewhere along the > lines of... > > #if > # define INT_64_T_FMT "%ld" > #else > # define INT_64_T_FMT "%lld" > #endif > > but I have no idea where to put such a thing in FreeBSD. Opinions? > Also, I guess I'd really need to do a modifier rather than a format, > for full generality. You need to include inttypes.h, which includes machine/_inttypes.h. This will provide the appropriate macro which in this case is PRId64. Sean -- scf@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 18:54:02 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 7DA22106566B for ; Sun, 5 Jun 2011 18:54:02 +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 112E68FC0A for ; Sun, 5 Jun 2011 18:54:01 +0000 (UTC) Received: by wwc33 with SMTP id 33so3132640wwc.31 for ; Sun, 05 Jun 2011 11:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F3ESePeq4fcKK2OzxtQiJGbLk968/K2RoUqvr99SlcY=; b=vBywaoXQiE8NMTn85g/7eVi7atdHfYOfjRGO2SyaGKJHIxZQ5AFqplDL2uRslR9J5Z QRIoWFoZEZmIFzXnb0rkSzSkDtaCBHQH0m1zSsJuopKu+dZXUo3rwFI36gdKS6x6U+mF 7aRvw0vFkLokICcA0y5Hri6bR01cYGk81Ef/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Xn2LVR3TcfpL7NC6gHDSRUBDfhGaImHQIHnGGf6xKJc9Irm1KalRHnZ8hrnBjXsTMQ VdXCMqYF0fSLO/Ix2U2irzjw5att8yHbTtePNNn57bCbIZDbPd7wTqkhJ0PLM8t7PPoo ZUYpKwukw0VIaHZzy4MqHxDIvVCV6PN0VG070= MIME-Version: 1.0 Received: by 10.216.141.1 with SMTP id f1mr4050820wej.35.1307298636998; Sun, 05 Jun 2011 11:30:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.93.193 with HTTP; Sun, 5 Jun 2011 11:30:36 -0700 (PDT) In-Reply-To: <4DEBC741.1020200@links.org> References: <4DEBC741.1020200@links.org> Date: Sun, 5 Jun 2011 11:30:36 -0700 X-Google-Sender-Auth: hNY62-NM0qVvo1H8Q4zlPF_bj7w Message-ID: From: mdf@FreeBSD.org To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 18:54:02 -0000 On Sun, Jun 5, 2011 at 11:13 AM, Ben Laurie wrote: > So, for example int64_t has no printf modifier I am aware of. Likewise > its many friends. The worse option is to use the C99 defines, like PRI64 and PRI64U. The better option is to use %jd / %ju and cast the value to [u]intmax_t. Cheers, matthew > In the past I've handled this by having a define somewhere along the > lines of... > > #if > # define INT_64_T_FMT "%ld" > #else > # define INT_64_T_FMT "%lld" > #endif > > but I have no idea where to put such a thing in FreeBSD. Opinions? Also, > I guess I'd really need to do a modifier rather than a format, for full > generality. > > -- > http://www.apache-ssl.org/ben.html =A0 =A0 =A0 =A0 =A0 http://www.links.o= rg/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > _______________________________________________ > 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 Sun Jun 5 19:06:45 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 26D97106566B; Sun, 5 Jun 2011 19:06:45 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id BBA868FC15; Sun, 5 Jun 2011 19:06:44 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 5A48A1DD648; Sun, 5 Jun 2011 21:06:43 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 42717173D9; Sun, 5 Jun 2011 21:06:43 +0200 (CEST) Date: Sun, 5 Jun 2011 21:06:43 +0200 From: Jilles Tjoelker To: "Sean C. Farley" Message-ID: <20110605190643.GA62966@stack.nl> References: <4DEBC741.1020200@links.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@FreeBSD.org, Ben Laurie Subject: Re: int64_t and printf 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, 05 Jun 2011 19:06:45 -0000 On Sun, Jun 05, 2011 at 02:31:27PM -0400, Sean C. Farley wrote: > On Sun, 5 Jun 2011, Ben Laurie wrote: > > So, for example int64_t has no printf modifier I am aware of. Likewise > > its many friends. > > In the past I've handled this by having a define somewhere along the > > lines of... > > #if > > # define INT_64_T_FMT "%ld" > > #else > > # define INT_64_T_FMT "%lld" > > #endif > > but I have no idea where to put such a thing in FreeBSD. Opinions? > > Also, I guess I'd really need to do a modifier rather than a format, > > for full generality. > You need to include inttypes.h, which includes machine/_inttypes.h. > This will provide the appropriate macro which in this case is PRId64. The macros from are certainly valid, but the style in most of FreeBSD prefers casting to a type such as intmax_t or uintmax_t for which a constant format string is available (%jd/%ju). In the particular case of int64_t, it would seem that long long is better than intmax_t, as it is possibly shorter but still guaranteed large enough by C99, but there are objections against this that I do not understand. Also, note the format strings for size_t, %zu, and for ptrdiff_t, %td. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 18:37:14 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 9414E106564A for ; Sun, 5 Jun 2011 18:37:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 531028FC13 for ; Sun, 5 Jun 2011 18:37:13 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1A6375D83; Sun, 5 Jun 2011 18:21:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p55ILOCY011706; Sun, 5 Jun 2011 18:21:24 GMT (envelope-from phk@critter.freebsd.dk) To: Ben Laurie From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 05 Jun 2011 19:13:21 +0100." <4DEBC741.1020200@links.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 05 Jun 2011 18:21:24 +0000 Message-ID: <11705.1307298084@critter.freebsd.dk> Sender: phk@critter.freebsd.dk X-Mailman-Approved-At: Sun, 05 Jun 2011 19:37:14 +0000 Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 18:37:14 -0000 In message <4DEBC741.1020200@links.org>, Ben Laurie writes: >So, for example int64_t has no printf modifier I am aware of. Likewise >its many friends. >but I have no idea where to put such a thing in FreeBSD. Opinions? I have totally given up on this mess. At best you get incredibly messy source code, at worst you waste a lot of time figuring out why who to define stuff to make some platform you have only heard rumours about behave. I have therefore resorted to printf'ing any typedefed integer type using "%jd" and an explicit cast to (intmax_t): printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf); If some system introduces int512_t that may not be optimal, but since printf is a pretty slow operation anyway, I doubt it will hurt even half as much as the alternative. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 20:04: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 391E2106566B; Sun, 5 Jun 2011 20:04:43 +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 551358FC0A; Sun, 5 Jun 2011 20:04:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA10001; Sun, 05 Jun 2011 23:04:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QTJYu-00082x-IJ; Sun, 05 Jun 2011 23:04:40 +0300 Message-ID: <4DEBE157.8030201@FreeBSD.org> Date: Sun, 05 Jun 2011 23:04:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jung-uk Kim References: <201105241356.45543.jkim@FreeBSD.org> <201106011655.51233.jkim@FreeBSD.org> <4DE8794B.60100@FreeBSD.org> <201106031228.58113.jkim@FreeBSD.org> In-Reply-To: <201106031228.58113.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP 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, 05 Jun 2011 20:04:43 -0000 on 03/06/2011 19:28 Jung-uk Kim said the following: > Unlike Intel, AMD did not guarantee "all TSCs reset to zero with RESET > IPI" before Bulldozer[1]. In fact, I tried to measure deltas between > cores when I started hacking on it using some crude heuristics, > somewhat like the OpenSolaris hack[2]. Basically, a dual-core AMD > Family 10h processor showed noticeably larger deltas than *two* > dual-core Intel Woodcrest Xeons'. You are right. I haven't had any problems with my Athlon II system with forced smp_tsc, but testing shows that it has a measurable difference in TSC between cores. E.g. with the "tsc_check" code: cpus 0-1, min_write_time = 186, tdelta = 316 cpus 0-1, TSCs are considered to be OUT of sync > [1] I couldn't find any clues from their publicly available documents > whether they will implement (or need) additional mechanism for > multi-socket Bulldozer platforms. It only says something like "all > TSCs are synchronized with a clock source in north bridge". We will > see when AMD Valencia & Interlagos are available. :-) > [2] Unfortunately, there is no way to accurately measure it with > current generation hardware. Yeah, quite unfortunate. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 20:17:40 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 2393E106566B for ; Sun, 5 Jun 2011 20:17:40 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id CAB6F8FC0A for ; Sun, 5 Jun 2011 20:17:39 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 85A9D33C1D; Sun, 5 Jun 2011 21:17:38 +0100 (BST) Message-ID: <4DEBE469.5060305@links.org> Date: Sun, 05 Jun 2011 21:17:45 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Poul-Henning Kamp References: <11705.1307298084@critter.freebsd.dk> In-Reply-To: <11705.1307298084@critter.freebsd.dk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 20:17:40 -0000 On 05/06/2011 19:21, Poul-Henning Kamp wrote: > In message <4DEBC741.1020200@links.org>, Ben Laurie writes: > >> So, for example int64_t has no printf modifier I am aware of. Likewise >> its many friends. > >> but I have no idea where to put such a thing in FreeBSD. Opinions? > > I have totally given up on this mess. > > At best you get incredibly messy source code, at worst you waste a > lot of time figuring out why who to define stuff to make some platform > you have only heard rumours about behave. > > I have therefore resorted to printf'ing any typedefed integer type using > "%jd" and an explicit cast to (intmax_t): > > printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf); > > If some system introduces int512_t that may not be optimal, but > since printf is a pretty slow operation anyway, I doubt it will > hurt even half as much as the alternative. My objection to this approach is the lack of type-safety - t could be anything and this would continue to work. Using PRId64 at least ensures that t is of an appropriate type. One way to get the best of both worlds is to at least ensure that t is of the type you think it is before casting, but this also leads to messy code - the best I can think of would look like printf("%-30s -> %jd -> %s\n", s, cast(int64_t, intmax_t, t), buf); Is this really better than printf("%-30s -> %" PRId64 " -> %s\n", s, t, buf); ? Mere character count would suggest not. Providing a better printf seems like an even smarter idea, e.g. printf("%-30s -> %I64d -> %s\n", s, t, buf); -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 20:40:34 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 A853E106566B for ; Sun, 5 Jun 2011 20:40:34 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFAB8FC14 for ; Sun, 5 Jun 2011 20:40:34 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 58C7A33C1C; Sun, 5 Jun 2011 21:40:33 +0100 (BST) Message-ID: <4DEBE9C7.4030505@links.org> Date: Sun, 05 Jun 2011 21:40:39 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Sean C. Farley" References: <4DEBC741.1020200@links.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: Re: int64_t and printf 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, 05 Jun 2011 20:40:34 -0000 On 05/06/2011 19:31, Sean C. Farley wrote: > On Sun, 5 Jun 2011, Ben Laurie wrote: > >> So, for example int64_t has no printf modifier I am aware of. Likewise >> its many friends. >> >> In the past I've handled this by having a define somewhere along the >> lines of... >> >> #if >> # define INT_64_T_FMT "%ld" >> #else >> # define INT_64_T_FMT "%lld" >> #endif >> >> but I have no idea where to put such a thing in FreeBSD. Opinions? >> Also, I guess I'd really need to do a modifier rather than a format, >> for full generality. > > You need to include inttypes.h, which includes machine/_inttypes.h. This > will provide the appropriate macro which in this case is PRId64. I somewhat love this plan. Apparently it doesn't work: /scratch/tmp/benl/work/head/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c:963:40: error: expected ')' (void) snprintf(c, sizeof (c), "0x%" PRIx64, addr); ^ (ref9-amd64). -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 20:42:47 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 D699A1065672 for ; Sun, 5 Jun 2011 20:42:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 968618FC1B for ; Sun, 5 Jun 2011 20:42:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0BFFF5E16; Sun, 5 Jun 2011 20:42:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p55KgjaP012272; Sun, 5 Jun 2011 20:42:45 GMT (envelope-from phk@critter.freebsd.dk) To: Ben Laurie From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 05 Jun 2011 21:17:45 +0100." <4DEBE469.5060305@links.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 05 Jun 2011 20:42:45 +0000 Message-ID: <12271.1307306565@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 20:42:47 -0000 In message <4DEBE469.5060305@links.org>, Ben Laurie writes: >On 05/06/2011 19:21, Poul-Henning Kamp wrote: >> In message <4DEBC741.1020200@links.org>, Ben Laurie writes: >> I have therefore resorted to printf'ing any typedefed integer type using >> "%jd" and an explicit cast to (intmax_t): >> >> printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf); > >My objection to this approach is the lack of type-safety - t could be >anything and this would continue to work. > >Using PRId64 at least ensures that t is of an appropriate type. Uhm, no, it doesn't. At best it allows the compiler to make well chosen assumptions about what the printf(3) function does. Printf-format warnings are usually lost as soon as you go through stdarg/v*printf, because people don't know they should add __printflike() and other nonportable gunk to their prototypes. And they are totally lost if you use extended printf formatting of any kind, because there is no way to tell the compiler that "%Y takes a void *" This is basically why the work I did in is practically useless. But worse: PRId64 only works if you know your variable actually is 64bit. If you are trying to write code which works with typedefs on both 32 and 64 bit platforms you cannot know this. It's all nice and dandy that they made a magic "z" letter for size_t, but what about uid_t, gid_t, pid_t, off_t, ino_t, mode_t, nlink_t, fflags_t and so on ? You will therefore be forced to cast your argument to (int64_t) before you can use PRId64 safely on it. Now you have messed up the format string without loosing the cast and now your code will DTWT once somebody typedefs pid_t to int71_t. >Providing a better printf seems like an even smarter idea, e.g. > > printf("%-30s -> %I64d -> %s\n", s, t, buf); Same problem as above. There is no way to do this sanely, without involving the compiler. At the very least, the compiler would need to mangle the format string, so that you write: printf("%-30?d\n", sometype) and the compiler replaces the '?' with whatever is suitable for the width of the argument. Alternatively, and more useful, would be a type-safe or at least type-aware stdarg, so that prinf(3) could ask about the width and type of the next argument. Both would be wonderful additions to ISO-C but you can produce a college fresh-man from scratch starting now, before that happens. (See also Bjarnes approx. 1985 discussion of why C++ overloads << instead of providing printf(3)). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 21:10:59 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 2B96F1065673 for ; Sun, 5 Jun 2011 21:10:59 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id 96C5A8FC17 for ; Sun, 5 Jun 2011 21:10:58 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 63D7733C1E; Sun, 5 Jun 2011 22:10:57 +0100 (BST) Message-ID: <4DEBF0E7.3040304@links.org> Date: Sun, 05 Jun 2011 22:11:03 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Poul-Henning Kamp References: <12271.1307306565@critter.freebsd.dk> In-Reply-To: <12271.1307306565@critter.freebsd.dk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 21:10:59 -0000 On 05/06/2011 21:42, Poul-Henning Kamp wrote: > In message <4DEBE469.5060305@links.org>, Ben Laurie writes: >> On 05/06/2011 19:21, Poul-Henning Kamp wrote: >>> In message <4DEBC741.1020200@links.org>, Ben Laurie writes: > >>> I have therefore resorted to printf'ing any typedefed integer type using >>> "%jd" and an explicit cast to (intmax_t): >>> >>> printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf); >> >> My objection to this approach is the lack of type-safety - t could be >> anything and this would continue to work. >> >> Using PRId64 at least ensures that t is of an appropriate type. > > Uhm, no, it doesn't. > > At best it allows the compiler to make well chosen assumptions > about what the printf(3) function does. > > Printf-format warnings are usually lost as soon as you go through > stdarg/v*printf, because people don't know they should add > __printflike() and other nonportable gunk to their prototypes. > > And they are totally lost if you use extended printf formatting > of any kind, because there is no way to tell the compiler that > "%Y takes a void *" > > This is basically why the work I did in is practically > useless. > > But worse: PRId64 only works if you know your variable actually is 64bit. > > If you are trying to write code which works with typedefs on both > 32 and 64 bit platforms you cannot know this. > > It's all nice and dandy that they made a magic "z" letter for size_t, > but what about uid_t, gid_t, pid_t, off_t, ino_t, mode_t, nlink_t, > fflags_t and so on ? > > You will therefore be forced to cast your argument to (int64_t) > before you can use PRId64 safely on it. > > Now you have messed up the format string without loosing the cast > and now your code will DTWT once somebody typedefs pid_t to int71_t. > >> Providing a better printf seems like an even smarter idea, e.g. >> >> printf("%-30s -> %I64d -> %s\n", s, t, buf); > > Same problem as above. > > There is no way to do this sanely, without involving the compiler. > > At the very least, the compiler would need to mangle the format > string, so that you write: > > printf("%-30?d\n", sometype) > > and the compiler replaces the '?' with whatever is suitable > for the width of the argument. > > Alternatively, and more useful, would be a type-safe or at least > type-aware stdarg, so that prinf(3) could ask about the width > and type of the next argument. > > Both would be wonderful additions to ISO-C but you can produce a > college fresh-man from scratch starting now, before that happens. > > (See also Bjarnes approx. 1985 discussion of why C++ overloads << > instead of providing printf(3)). > Your points are taken. I note that you didn't react to my other wherein you cast from known type A to known type B. I supposed it would be smart to also assert that the cast was non-narrowing. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 21:24:07 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 4C5981065672 for ; Sun, 5 Jun 2011 21:24:07 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7218FC15 for ; Sun, 5 Jun 2011 21:24:06 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E56D15E31; Sun, 5 Jun 2011 21:24:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p55LO5NN012619; Sun, 5 Jun 2011 21:24:05 GMT (envelope-from phk@critter.freebsd.dk) To: Ben Laurie From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 05 Jun 2011 22:11:03 +0100." <4DEBF0E7.3040304@links.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 05 Jun 2011 21:24:05 +0000 Message-ID: <12618.1307309045@critter.freebsd.dk> Sender: phk@critter.freebsd.dk X-Mailman-Approved-At: Sun, 05 Jun 2011 21:31:47 +0000 Cc: hackers@freebsd.org Subject: Re: int64_t and printf 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, 05 Jun 2011 21:24:07 -0000 In message <4DEBF0E7.3040304@links.org>, Ben Laurie writes: >I note that you didn't react to my other wherein you cast from known >type A to known type B. I supposed it would be smart to also assert that >the cast was non-narrowing. Well, if casting to intmax_t is narrowing I think I have bigger problems on my hands :-) I've spent a fair amount of time agonizing over this in Varnish and I came to the conclusion that the my time spent trying to establish if something narrower than intmax_t was safe would never amortize the performance difference of printing an intmax_t vs. intN_t, so now I just cast anything that that's typedef'ed to intmax_t and move on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 17:18:16 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 316DB1065672 for ; Mon, 6 Jun 2011 17:18:16 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E37E8FC0C for ; Mon, 6 Jun 2011 17:18:15 +0000 (UTC) Received: by bwz12 with SMTP id 12so5304660bwz.13 for ; Mon, 06 Jun 2011 10:18:14 -0700 (PDT) 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=/698JYbNtuStdKh9TLOQgXMVo2ZFU//Cr3xt7gHp2dM=; b=xvH+XS5/gmUomB2CaU9iydLbYckkeN5B2Gbnd9E9khiQJk3FEa5L+/qpSQT517R1Km pQcRPlj3ddBh5eO5La8Xrsfshp2nsESwRbqcyvA+VxjpxakSh8Mm0sUaR4humCnpehZt PRdqGBnXJKs99Cy9c8EqSRKppD2kepKBKHlWo= 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=Le5pY+k/CkELT7obPLuPeo555v28aVUTcWriT/22x2V3ANRy78rSnlwctPfsqWy0Hm 8PQujQd1UneUhYUegQFMA3UYeZQEkTxcL4pvbB4RBy/TWPjm9rlRi6cr88DhjCQsYna5 abZM34c2pJvqCsm0A7+lVmQWumKsQLngo9kME= MIME-Version: 1.0 Received: by 10.204.233.11 with SMTP id jw11mr5134886bkb.32.1307380694319; Mon, 06 Jun 2011 10:18:14 -0700 (PDT) Received: by 10.204.40.3 with HTTP; Mon, 6 Jun 2011 10:18:14 -0700 (PDT) In-Reply-To: <201106021034.16366.jhb@freebsd.org> References: <201106021034.16366.jhb@freebsd.org> Date: Mon, 6 Jun 2011 21:18:14 +0400 Message-ID: From: Dmitry Krivenok To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Bug in ksched_setscheduler? 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, 06 Jun 2011 17:18:16 -0000 I've submitted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=3D157657. Dmitry On Thu, Jun 2, 2011 at 6:34 PM, John Baldwin wrote: > On Wednesday, June 01, 2011 12:42:42 pm Dmitry Krivenok wrote: >> Hello Hackers, >> I think I found a bug in ksched_setscheduler() function. >> >> 209 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rtp.prio =3D p4prio_= to_rtpprio(param->sched_priority); >> >> Shouldn't we use p4prio_to_tsprio instead of p4prio_to_rtpprio at the li= ne 209? >> This macro is defined but never used in kernel code: >> >> $ grep -r 'p4prio_to_tsprio' /usr/src/sys/ >> /usr/src/sys/kern/ksched.c:#define p4prio_to_tsprio(P) >> ((PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) - (P)) >> $ >> >> Is it a real bug or just my misunderstanding of something? > > I think it is a real bug. =A0Can you come up with a test case to show it? > > -- > John Baldwin > --=20 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 Mon Jun 6 19:47:40 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 7E2901065674 for ; Mon, 6 Jun 2011 19:47:40 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 103708FC17 for ; Mon, 6 Jun 2011 19:47:39 +0000 (UTC) Received: by gwb15 with SMTP id 15so2320536gwb.13 for ; Mon, 06 Jun 2011 12:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=RTvtjQe++rP5XqUd3j5FHzFr5Fy4f3PydJgS7j83sHo=; b=Hax8y0W+LpUV/T/A1hLg1C2aeHsuD9dKqFO15pjepzruKV6LCq6TGO1vCUv14d8li5 QzUZmeKgxaV1z658NCdfWz7WAcXiDKcmW8MhMjoKJyfMOVAtTCNueSOxVbbSAuymEpsh yuGtS+aJA7Kd3X66OQ+nUkVtVT4siQS7GIq5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=TOeMIxMcajDBpgly6PMFj5FvM6DTqBBEzhIWujNFp3L03qhi2y4VGBgCjTDzTgh+iL hsRCrUhAHUiN104FI9C2uROaQ9ls+DGYb9GJz8TOppO2n7qEy71VTWWhR1qfbi3sITwK 1C854qKYpOVOnLDFsx7cgYTYu3IAtcs8SFS6o= MIME-Version: 1.0 Received: by 10.236.78.99 with SMTP id f63mr6352709yhe.518.1307389658267; Mon, 06 Jun 2011 12:47:38 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Mon, 6 Jun 2011 12:47:38 -0700 (PDT) Date: Mon, 6 Jun 2011 12:47:38 -0700 X-Google-Sender-Auth: L-o8shgd1LA08TTYumhmpp1LPDw Message-ID: From: Artem Belevich To: "Jack F. Vogel" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers Subject: FreeBSD I/OAT (QuickData now?) driver 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, 06 Jun 2011 19:47:40 -0000 Jack, Quite a while back you've posted I/OAT driver. Unfortunately the link you posted does not seem to have the drivers any more. Do you still have them available somewhere? Do you know if Intel has technical info on the DMA engine available? I believe long time back when it was still I/OAT it was part of chipset spec. Now X58 Express chipset datasheet refers to a broken link http://www.intel.com/cs/network/connectivity/emea/eng/226276.htm --Artem From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 20:02: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 8ED6F106566C; Mon, 6 Jun 2011 20:02:07 +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 E4B288FC0C; Mon, 6 Jun 2011 20:02:06 +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 p56K20Ck003027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2011 23:02:00 +0300 (EEST) (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 p56K20bT079072; Mon, 6 Jun 2011 23:02:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p56K20EH079071; Mon, 6 Jun 2011 23:02:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Jun 2011 23:02:00 +0300 From: Kostik Belousov To: Artem Belevich Message-ID: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5wAPvwbAcQJrmmvx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 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: "Jack F. Vogel" , FreeBSD Hackers Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 06 Jun 2011 20:02:07 -0000 --5wAPvwbAcQJrmmvx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 06, 2011 at 12:47:38PM -0700, Artem Belevich wrote: > Jack, >=20 > Quite a while back you've posted I/OAT driver. Unfortunately the link > you posted does not seem to have the drivers any more. Do you still > have them available somewhere? >=20 > Do you know if Intel has technical info on the DMA engine available? I > believe long time back when it was still I/OAT it was part of chipset > spec. Now X58 Express chipset datasheet refers to a broken link > http://www.intel.com/cs/network/connectivity/emea/eng/226276.htm Referencing DMA engine, do you mean Vanderpool ? It is http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for= _Direct_IO.pdf According to Intel marketing-talk, I/OAT is a couple of things, including MSI-X, VT-d (i.e. IOMMU/Vanderpool), something called Intel(R) QuickData Technology (might be, you mean this one ?) and DCA. --5wAPvwbAcQJrmmvx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3tMjgACgkQC3+MBN1Mb4j0OgCeNG/X59UsJm+nIvESrqzWbtce 1R8AoPdGdXr7pGfVOnK2+mbPh22uPSjm =MPKs -----END PGP SIGNATURE----- --5wAPvwbAcQJrmmvx-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 20:11:32 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 D25D5106566C; Mon, 6 Jun 2011 20:11:32 +0000 (UTC) (envelope-from artemb@gmail.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 796198FC1E; Mon, 6 Jun 2011 20:11:30 +0000 (UTC) Received: by yxd30 with SMTP id 30so1155434yxd.13 for ; Mon, 06 Jun 2011 13:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3dP2Ywh+Gubk06lo4d+I8p/H3Mfs0meulII9iE1wOEM=; b=xhUqZyVaapUSUu2zNpM9xtZgvB4H4Y8MHIduWfXEGt9/1DFZngUPk5xakd4+PmAd0p hPTVWNZJkPAFIsg6ISJPA823vg2dwCgpLhnNwd94lVriWquJccVdPxDuhcNeGHfF6xLq UdF8VCUfGnliAPcHmZwtDwZrmvVXobyAcUqI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YxY7VYGNhei2CM3gWCa08r0pvwnecmLWz21S+C73uJzh/CBTTsfe+brt+bESR6e+nP FG23ErSeVPaPGEL5VDk9ErTW9/9o+wzzsmV0UIq0z4KRHqxkzkYuPpKDFoay5MHWV1+G KcCOw9mHvSjcxoqLWLFj/xWHFH/q7l3p3UDUw= MIME-Version: 1.0 Received: by 10.236.156.104 with SMTP id l68mr6361044yhk.451.1307391090459; Mon, 06 Jun 2011 13:11:30 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Mon, 6 Jun 2011 13:11:30 -0700 (PDT) In-Reply-To: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> References: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> Date: Mon, 6 Jun 2011 13:11:30 -0700 X-Google-Sender-Auth: pVFpCLtfeRaH5IV_esH1Sq5bfb8 Message-ID: From: Artem Belevich To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "Jack F. Vogel" , FreeBSD Hackers Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 06 Jun 2011 20:11:33 -0000 On Mon, Jun 6, 2011 at 1:02 PM, Kostik Belousov wrote: > On Mon, Jun 06, 2011 at 12:47:38PM -0700, Artem Belevich wrote: >> Jack, >> >> Quite a while back you've posted I/OAT driver. Unfortunately the link >> you posted does not seem to have the drivers any more. Do you still >> have them available somewhere? >> >> Do you know if Intel has technical info on the DMA engine available? I >> believe long time back when it was still I/OAT it was part of chipset >> spec. Now X58 Express chipset datasheet refers to a broken link >> http://www.intel.com/cs/network/connectivity/emea/eng/226276.htm > > Referencing DMA engine, do you mean Vanderpool ? > It is http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf No. > According to Intel marketing-talk, I/OAT is a couple of things, > including MSI-X, VT-d (i.e. IOMMU/Vanderpool), something called Intel(R) > QuickData Technology (might be, you mean this one ?) and DCA. I believe QuickData is the term used now. I'm interested in DMA engine itself so it could do bulk data transfer from memory on peripheral into main RAM. On one of my boxes those DMA engines show up like this: none4@pci0:0:22:0: class=0x088000 card=0x060015d9 chip=0x34308086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none5@pci0:0:22:1: class=0x088000 card=0x060015d9 chip=0x34318086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none6@pci0:0:22:2: class=0x088000 card=0x060015d9 chip=0x34328086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none7@pci0:0:22:3: class=0x088000 card=0x060015d9 chip=0x34338086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none8@pci0:0:22:4: class=0x088000 card=0x060015d9 chip=0x34298086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none9@pci0:0:22:5: class=0x088000 card=0x060015d9 chip=0x342a8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none10@pci0:0:22:6: class=0x088000 card=0x060015d9 chip=0x342b8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral none11@pci0:0:22:7: class=0x088000 card=0x060015d9 chip=0x342c8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral --Artem From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 20:40: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 961E71065675; Mon, 6 Jun 2011 20:40:31 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCB18FC0C; Mon, 6 Jun 2011 20:40:31 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p56KNdne030562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2011 13:23:39 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p56KNddo030556; Mon, 6 Jun 2011 13:23:39 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 6 Jun 2011 13:23:39 -0700 (PDT) From: Matthew Jacob To: Artem Belevich In-Reply-To: Message-ID: References: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [127.0.0.1]); Mon, 06 Jun 2011 13:23:39 -0700 (PDT) Cc: Kostik Belousov , "Jack F. Vogel" , FreeBSD Hackers Subject: Re: FreeBSD I/OAT (QuickData now?) driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:40:31 -0000 At Panasas we were looking at using that for some background parity calculation. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 21:21:02 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 63578106566C; Mon, 6 Jun 2011 21:21:02 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id DB9398FC15; Mon, 6 Jun 2011 21:21:01 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p56LL1mY095364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2011 14:21:01 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p56LL0FK095341; Mon, 6 Jun 2011 14:21:01 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 6 Jun 2011 14:21:00 -0700 (PDT) From: Matthew Jacob To: Jack Vogel In-Reply-To: Message-ID: References: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [127.0.0.1]); Mon, 06 Jun 2011 14:21:01 -0700 (PDT) Cc: Kostik Belousov , Artem Belevich , "Jack F. Vogel" , FreeBSD Hackers Subject: Re: FreeBSD I/OAT (QuickData now?) driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 21:21:02 -0000 > > If there's really interest then perhaps I should get something together > that can actually be checked in?? Yes? Yes please. Since Sandybridge interest has been growing particularly where systems are being put together with bridges (non-transparent) with a notion that IO/AT could be used to move bytes. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 21:37: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 A8817106564A; Mon, 6 Jun 2011 21:37:46 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6270B8FC0C; Mon, 6 Jun 2011 21:37:46 +0000 (UTC) Received: by pwj8 with SMTP id 8so2990374pwj.13 for ; Mon, 06 Jun 2011 14:37:45 -0700 (PDT) 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=Ga/iZYvI2bkJL8hcDc2NMKVA4JJpDf2S8jZNO/0qmQw=; b=oZ/SkjLel2iruleHaiaXkRPPA7d2dez2Q/SmV82Vmudae5rUabBb6PKGiHxSosqkYX lXnfTxaLuKWw/IePY+P3ovFG3zetDO2qa7Sp2+SSgGk6b+xyvaxQ/L12p+TJhQIlojwI ogQHwjVFnuTxtl/ZDgZMEBImnGRW6A5j/nmvc= 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=mdrtjgRiNnkZN/ZdtoxfvOmroNTFYQae0WyBCs8aNNS6oc+A6MxitFAmI6OkOu+xy0 BpdxVc/df6EQtKmngSONL75jvXj1yAPLwmBrcaYZMICCP+zil4t6BMkWozACKfsVIf/4 stIX6nir0mkWCHHBPjP0SH2hMXC9o89TB40FE= MIME-Version: 1.0 Received: by 10.68.69.39 with SMTP id b7mr2256885pbu.403.1307396265794; Mon, 06 Jun 2011 14:37:45 -0700 (PDT) Received: by 10.68.52.164 with HTTP; Mon, 6 Jun 2011 14:37:44 -0700 (PDT) In-Reply-To: References: <4D934AF4.9080503@FreeBSD.org> <742085CD-7F6F-4879-9FFD-517EC3203D52@bsdimp.com> <5AF348C8-6AB6-490D-A12E-89A51528F58F@bsdimp.com> Date: Mon, 6 Jun 2011 17:37:44 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "Robert N. M. Watson" , Dimitry Andric , freebsd-hackers Subject: Re: Include file search path 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, 06 Jun 2011 21:37:46 -0000 Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh wrote: > > On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: > >> Hi Warner, >> >> On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh wrote: >>> >>> On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: >>> >>>> On 2 Apr 2011, at 19:47, Warner Losh wrote: >>>> >>>>>> (2) Working clang/LLVM cross-compile of FreeBSD. =A0This seems like = a basic >>>>>> =A0requirement to adopt clang/LLVM, and as far as I'm aware that's n= ot yet a >>>>>> =A0resolved issue? >>>>> >>>>> 0 work has been done here to my knowledge. =A0The world view for clan= g and our in-tree gcc differ which makes it a challenge. >>>> >>>> That's disappointing. I seem to recall it's more an issue of our build= integration with clang/LLVM than an underlying issue in clang/LLVM? >>> >>> Yes. =A0The problem isn't hard, the cross compile paradigm is just a li= ttle different. >>> >>>>>> We (Cambridge) are currently bringing up FreeBSD on a new soft-core = 64-bit MIPS platform. =A0We're already using a non-base gcc for our boot lo= ader work, and plan to move to using clang/LLVM later in the year. =A0The b= ase system seems a bit short on detail when it comes to the above, currentl= y. >>>>> >>>>> Yes. =A0I've had to add about a dozen changes so far to get close to = building with xdev compilers. =A0A similar number are needed to make it eas= y to configure and add systree support, I think. >>>> >>>> Sounds like great progress -- do you think we'll ship 9.0 in a "just w= orks" state with regard to this? >>> >>> I sure hope so. =A0I'd like to have demoable stuff by BSDcan. >>> >> BSDCan has passed, has there been any advance made since that discussion= ? > > It is "demonstrable" but not ready to commit to the tree. =A0Needs about = 4 hours of work that I've had trouble scheduling on it due to work getting = busier than I expected. > any chances to have a look at the patch or should I wait for the final comm= it ? Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 21:10: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 EB627106566C for ; Mon, 6 Jun 2011 21:10:23 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9814F8FC14 for ; Mon, 6 Jun 2011 21:10:23 +0000 (UTC) Received: by vxc34 with SMTP id 34so4406115vxc.13 for ; Mon, 06 Jun 2011 14:10:22 -0700 (PDT) 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; bh=VcwjVcSsMUncppgqiHYhwNUYaHIthXcPa4Qfh42F+Gg=; b=pvsNXb0lZrivme/kQI1YIjFkiy14vXedohWfOnIXgrCHKlKr3wDAA9IccmHe4xFLvT 2ixLFXRUJnuxBtWOuowfLQVe5rU40ygBRVY+N82Di8JcpG+yu+rJAHFv38KGH5xwWcmD ZWPgbWR+K7Js/laEHDQEqRoVJ9dLzJqLk5C58= 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; b=FVo0maS+kroK+KAOIaKvspaf/ZTsaQwuMBYyUyiW/8w7jVvoJnKKD41kghBigNWVP9 FHLgE9bCkRKKTwfWuKH1kc3bdCieMbOHDb0XSaZEjFji9T+ZATMXfi8LwOE8Rc9EUhQK F7qYx8PDEYRWsYDvx9a2fV89KSs0exYMoWN4k= MIME-Version: 1.0 Received: by 10.52.111.231 with SMTP id il7mr4765298vdb.58.1307393197961; Mon, 06 Jun 2011 13:46:37 -0700 (PDT) Received: by 10.52.107.97 with HTTP; Mon, 6 Jun 2011 13:46:37 -0700 (PDT) In-Reply-To: References: <20110606200200.GP48734@deviant.kiev.zoral.com.ua> Date: Mon, 6 Jun 2011 13:46:37 -0700 Message-ID: From: Jack Vogel To: mj@feral.com X-Mailman-Approved-At: Mon, 06 Jun 2011 22:26:40 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , Artem Belevich , "Jack F. Vogel" , FreeBSD Hackers Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 06 Jun 2011 21:10:24 -0000 My proto code is ancient now, like 4 years old I'm guessing, this is the most I've ever seen as far as interest in it :) The hardware has evolved so it really needs to be updated. If there's really interest then perhaps I should get something together that can actually be checked in?? Yes? Cheers, Jack On Mon, Jun 6, 2011 at 1:23 PM, Matthew Jacob wrote: > > At Panasas we were looking at using that for some background parity > calculation. > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 6 22:41:06 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 BB965106566C; Mon, 6 Jun 2011 22:41:06 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 609998FC1B; Mon, 6 Jun 2011 22:41:06 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 621C01DD630; Tue, 7 Jun 2011 00:41:05 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 5BC02173D9; Tue, 7 Jun 2011 00:41:05 +0200 (CEST) Date: Tue, 7 Jun 2011 00:41:05 +0200 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org, freebsd-i18n@freebsd.org Message-ID: <20110606224105.GA92410@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: tr A-Z a-z in locales other than C 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, 06 Jun 2011 22:41:06 -0000 A few years ago, when locale support was added to the tr utility, character ranges (except ones containing one or two octal escapes) were changed to use the collation order instead of the character code order. At the time, this matched other implementations of tr and was apparently somewhat generally accepted. However, this behaviour is not intuitive, not portable as it deeply depends on the collation order and it is very hard to find a useful use for it. Perhaps there is a use case in EBCDIC locales that only contain the 2*26 basic Latin letters, but that is rather exotic. The command tr A-Z a-z may do something unexpected even if there is an 1:1 mapping between upper and lower case, since it also assumes that 'z' is the last letter. This is not a POSIX issue as POSIX leaves character ranges in tr unspecified for locales other than the POSIX locale (except for ranges containing octal escapes). If there is no reason to keep using the collation order, I would like to change tr's character ranges back to character codes. GNU tr does this and many ports wrongly take advantage of it, so following it will reduce the need to patch ports. The below patch demonstrates the new behaviour. The code could be simplified more as the flags for octal escapes are no longer needed. The man page may need some additional change as well. In particular, the command tr "[:upper:]" "[:lower:]" in a user's locale is a good choice for text specified by the user, but a poor choice for doing case-insensitive comparisons of constant strings, because in Turkish locales the upper case version of 'i' is a capital I with dot and the lower case version of 'I' is a lower case i without dot. In such cases, LC_ALL=C tr "[:upper:]" "[:lower:]" may be a better option (A-Z a-z could be used at the cost of breaking EBCDIC support). There is a related issue with ranges in regular expressions, glob and fnmatch (likewise unspecified by POSIX outside the POSIX locale), but this is less likely to cause problems. Index: usr.bin/tr/tr.1 =================================================================== --- usr.bin/tr/tr.1 (revision 222648) +++ usr.bin/tr/tr.1 (working copy) @@ -31,7 +31,7 @@ .\" @(#)tr.1 8.1 (Berkeley) 6/6/93 .\" $FreeBSD$ .\" -.Dd October 13, 2006 +.Dd June 6, 2011 .Dt TR 1 .Os .Sh NAME @@ -158,12 +158,7 @@ .Pp A backslash followed by any other character maps to that character. .It c-c -For non-octal range endpoints -represents the range of characters between the range endpoints, inclusive, -in ascending order, -as defined by the collation sequence. -If either or both of the range endpoints are octal sequences, it -represents the range of specific coded values between the +A range represents the range of specific coded values between the range endpoints, inclusive. .Pp .Bf Em @@ -309,20 +304,18 @@ .Pp .Dl "tr \*q[=e=]\*q \*qe\*q" .Sh COMPATIBILITY -Previous -.Fx -implementations of -.Nm -did not order characters in range expressions according to the current -locale's collation order, making it possible to convert unaccented Latin +Some implementations of +.Nm , +including the ones in previous versions of +.Fx , +order characters in range expressions according to the current +locale's collation order, making it impossible to convert unaccented Latin characters (esp.\& as found in English text) from upper to lower case using the traditional .Ux idiom of .Dq Li "tr A-Z a-z" . -Since -.Nm -now obeys the locale's collation order, this idiom may not produce +In such implementations, this idiom may not produce correct results when there is not a 1:1 mapping between lower and upper case, or when the order of characters within the two cases differs. As noted in the Index: usr.bin/tr/str.c =================================================================== --- usr.bin/tr/str.c (revision 222648) +++ usr.bin/tr/str.c (working copy) @@ -260,37 +260,13 @@ stopval = wc; s->str += clen; } - /* - * XXX Characters are not ordered according to collating sequence in - * multibyte locales. - */ - if (octal || was_octal || MB_CUR_MAX > 1) { - if (stopval < s->lastch) { - s->str = savestart; - return (0); - } - s->cnt = stopval - s->lastch + 1; - s->state = RANGE; - --s->lastch; - return (1); - } - if (charcoll((const void *)&stopval, (const void *)&(s->lastch)) < 0) { + if (stopval < s->lastch) { s->str = savestart; return (0); } - if ((s->set = p = malloc((NCHARS_SB + 1) * sizeof(int))) == NULL) - err(1, "genrange() malloc"); - for (cnt = 0; cnt < NCHARS_SB; cnt++) - if (charcoll((const void *)&cnt, (const void *)&(s->lastch)) >= 0 && - charcoll((const void *)&cnt, (const void *)&stopval) <= 0) - *p++ = cnt; - *p = OOBCH; - n = p - s->set; - - s->cnt = 0; - s->state = SET; - if (n > 1) - mergesort(s->set, n, sizeof(*(s->set)), charcoll); + s->cnt = stopval - s->lastch + 1; + s->state = RANGE; + --s->lastch; return (1); } -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 00:37: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 C87041065673; Tue, 7 Jun 2011 00:37:31 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 440DE8FC17; Tue, 7 Jun 2011 00:37:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p570OiPD089765; Tue, 7 Jun 2011 04:24:44 +0400 (MSD) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.4/8.14.4/Submit) id p570OheP089764; Tue, 7 Jun 2011 04:24:43 +0400 (MSD) (envelope-from ache) Date: Tue, 7 Jun 2011 04:24:43 +0400 From: Andrey Chernov To: Jilles Tjoelker Message-ID: <20110607002442.GA89483@vniz.net> Mail-Followup-To: Andrey Chernov , Jilles Tjoelker , freebsd-hackers@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG References: <20110606224105.GA92410@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110606224105.GA92410@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG Subject: Re: tr A-Z a-z in locales other than C 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, 07 Jun 2011 00:37:31 -0000 On Tue, Jun 07, 2011 at 12:41:05AM +0200, Jilles Tjoelker wrote: > > There is a related issue with ranges in regular expressions, glob and > fnmatch (likewise unspecified by POSIX outside the POSIX locale), but > this is less likely to cause problems. > You care about ports, but suggested change is americano-centrism which kills tr usage for national language documents due to impossibility to specify whole national alphabet easily, just by two letters. Moreover, having differently treated regex ranges in tr vs other places you mention will produce additional chaos. Back to the ports: it is not hard to run _any_ port's make or configure with LANG=C directly by the ports Mk system to eliminate that problem. -- http://ache.vniz.net/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 02:40: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 5A6E1106566B; Tue, 7 Jun 2011 02:40:01 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 29B468FC18; Tue, 7 Jun 2011 02:40:00 +0000 (UTC) Received: by pzk27 with SMTP id 27so2858202pzk.13 for ; Mon, 06 Jun 2011 19:40:00 -0700 (PDT) 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:cc :content-type; bh=HhX1sIuieNFOALi93vruWnBXB+SHfk6Ax3hdJp26dvU=; b=u9SDORZxj2Rb+oMOJ4+Unt79L0zYASy0vJ1tubrWy/xSWpwYYuCv9bKLxj8rLJYcws VQg5cnKlhKuONOU1bihitgY3ah4cHLcKQW7Kb9NYVQ2Rduc6HyufJPvURRQhY4UqUjJi MByaBL0B8Oa1tgBQ0s+SuIm7Acflbc43lYebA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=oZQl+gj09o3kMzVorc09okZq2bfpNnj1cIAGXJegyWcFKMqvtNe80supzBRcfBLgE7 SAQ/qQUWraMoqhB6BkIZmMCfURDW0S/2pb/AyM1f0Vwx42B6AHqkw+OV9eCEUEohJlYM qBHc5gOmoA1IwC3bMuxKR6sickXQdBOEO4RS8= MIME-Version: 1.0 Received: by 10.143.21.38 with SMTP id y38mr1095138wfi.342.1307412831553; Mon, 06 Jun 2011 19:13:51 -0700 (PDT) Received: by 10.142.131.19 with HTTP; Mon, 6 Jun 2011 19:13:51 -0700 (PDT) Date: Mon, 6 Jun 2011 22:13:51 -0400 Message-ID: From: grarpamp To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 07 Jun 2011 04:48:56 +0000 Cc: freebsd-net@freebsd.org Subject: FreeBSD I/OAT (QuickData now?) driver 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, 07 Jun 2011 02:40:01 -0000 Is this work part of what's needed to enable the FreeBSD equivalent of TNAPI? I know we've got polling. And probably MSI-X in a couple drivers. Pretty sure there is still one CPU doing the interrupt work? And none of the multiple queue thread spreading tech exists? http://www.ntop.org/blog http://www.ntop.org/TNAPI.html TNAPI attempts to solve the following problems: * Distribute the traffic across cores (i.e. the more core the more scalable is your networking application) for improving scalability. * Poll packets simultaneously from each RX queue (contraty to sequential NAPI polling) for fetching packets as fast as possible hence improve performance. * Through PF_RING, expose the RX queues to the userland so that the application can spawn one thread per queue hence avoid using semaphores at all. TNAPI achieves all this by starting one thread per RX queue. Received packets are then pushed to PF_RING (if available) or through the standard Linux stack. However in order to fully exploit this technology it is necessary to use PF_RING as it provides a straight packet path from kernel to userland. Furthermore it allows to create a virtual ethernet card per RX queue. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 05:24:16 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 96669106564A; Tue, 7 Jun 2011 05:24:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAA48FC13; Tue, 7 Jun 2011 05:24:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6AA6F7300A; Tue, 7 Jun 2011 07:24:00 +0200 (CEST) Date: Tue, 7 Jun 2011 07:24:00 +0200 From: Luigi Rizzo To: grarpamp Message-ID: <20110607052400.GC4840@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 07 Jun 2011 05:24:16 -0000 On Mon, Jun 06, 2011 at 10:13:51PM -0400, grarpamp wrote: > Is this work part of what's needed to enable the FreeBSD > equivalent of TNAPI? > > I know we've got polling. And probably MSI-X in a couple drivers. > Pretty sure there is still one CPU doing the interrupt work? > And none of the multiple queue thread spreading tech exists? i have heard of some Gsoc work that addresses the problem for cards that have a single queue, but drivers for other cards with native multiqueue (e.g. ixgbe, e1000 drivers) seem to have the ability to use one cpu per queue. I'd argue that for many types of applications (basically all for which PF_RING/TNAPI were designed), spreading work across cores is a second order problem, you should first avoid doing useless work. Please have a look at http://info.iet.unipi.it/~luigi/netmap/ which addresses both issues. cheers luigi > http://www.ntop.org/blog > http://www.ntop.org/TNAPI.html > TNAPI attempts to solve the following problems: > * Distribute the traffic across cores (i.e. the more core the more > scalable is your networking application) for improving scalability. > * Poll packets simultaneously from each RX queue (contraty to > sequential NAPI polling) for fetching packets as fast as possible > hence improve performance. > * Through PF_RING, expose the RX queues to the userland so that > the application can spawn one thread per queue hence avoid using > semaphores at all. > TNAPI achieves all this by starting one thread per RX queue. Received > packets are then pushed to PF_RING (if available) or through the > standard Linux stack. However in order to fully exploit this > technology it is necessary to use PF_RING as it provides a straight > packet path from kernel to userland. Furthermore it allows to create a > virtual ethernet card per RX queue. > _______________________________________________ > 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 Tue Jun 7 12:15:34 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 75FDD106566B for ; Tue, 7 Jun 2011 12:15:34 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFD38FC08 for ; Tue, 7 Jun 2011 12:15:34 +0000 (UTC) Received: by vxc34 with SMTP id 34so4986362vxc.13 for ; Tue, 07 Jun 2011 05:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aGJ0+/a5cRckLE6I72sy816TLmuUY1FytzyL1Xy+e7g=; b=G0NDG1eoXE1aCiXalrGSZXLZrFBlwhn7s2hzxDjDYp/M56daMCDNqqcajpRMJwRfuI OQpJhYjpMu+I5wMOV12TeL4oab4ZwyGK33sSpRXYu8ViMr0Td0Lny+Jc43ysCOtgn2X1 yD13+dw0DdL+IpKec21Rz6ic2KacIvhZHXctI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=J9gA2pM0ewHJ71gxY/l6q4HYwa/V0ewrwhh+F9AFThnH5jfA8ubz+w3aRXcZU9gilL YCvgqmCoH6p1zKhfYARKGhfChSfsqZCGN4CfzdOPhV0esRVntewoaDme/PfzVSwUzqU3 7E5kz7jOSOHzs5I6HkfBLEqK1FDJWV+1YeCbM= MIME-Version: 1.0 Received: by 10.52.177.234 with SMTP id ct10mr5383646vdc.2.1307447516943; Tue, 07 Jun 2011 04:51:56 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.74 with HTTP; Tue, 7 Jun 2011 04:51:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 13:51:56 +0200 X-Google-Sender-Auth: I-iQZjUd_oolg_CNn8ERImaG6ys Message-ID: From: "K. Macy" To: grarpamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 07 Jun 2011 12:15:34 -0000 All 10GigE NICs and some newer 10 GigE NICs have multiple hardware queues with a separate MSI-x vector per queue, where each vector is directed to a different CPU. The current operating model is to have a separate interrupt thread per vector. This obviously gets bogged down if one has multiple cards as the interrupt threads end up requiring the scheduler to distribute work fairly between cards as multiple threads will end up running on the same CPUs. Nokia had a reasonable interface for coping with this that was reminiscent of NAPI whereby cooperative sharing between interfaces was provided by having a single taskqueue thread per-core and the cards would queue tasks (which would be re-queued if more than a certain amount of work were required) as interrupts were delivered. There has been talk off and on of porting this "net_task" interface to freebsd. None of this addresses PF_RING's facility for pushing packets in to userland - but presumably Rizzo's netmap work addresses those in need of that sufficiently. Cheers, Kip On Tue, Jun 7, 2011 at 4:13 AM, grarpamp wrote: > Is this work part of what's needed to enable the FreeBSD > equivalent of TNAPI? > > I know we've got polling. And probably MSI-X in a couple drivers. > Pretty sure there is still one CPU doing the interrupt work? > And none of the multiple queue thread spreading tech exists? > > http://www.ntop.org/blog > http://www.ntop.org/TNAPI.html > TNAPI attempts to solve the following problems: > =A0 =A0* Distribute the traffic across cores (i.e. the more core the more > scalable is your networking application) for improving scalability. > =A0 =A0* Poll packets simultaneously from each RX queue (contraty to > sequential NAPI polling) for fetching packets as fast as possible > hence improve performance. > =A0 =A0* Through PF_RING, expose the RX queues to the userland so that > the application can spawn one thread per queue hence avoid using > semaphores at all. > TNAPI achieves all this by starting one thread per RX queue. Received > packets are then pushed to PF_RING (if available) or through the > standard Linux stack. However in order to fully exploit this > technology it is necessary to use PF_RING as it provides a straight > packet path from kernel to userland. Furthermore it allows to create a > virtual ethernet card per RX queue. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 17:32:08 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 90627106566B for ; Tue, 7 Jun 2011 17:32:08 +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 1FCC48FC0A for ; Tue, 7 Jun 2011 17:32:07 +0000 (UTC) Received: by wwc33 with SMTP id 33so5263111wwc.31 for ; Tue, 07 Jun 2011 10:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=55oAs5w9B15ddHsLTHTa1xSX/Pbkpq9rnm341y1JwpU=; b=DYNr9vrZF3e1piXFBAPM9fLakPItU9s+wMftfIYi8h2gETL3kDKLnMXh7RcxrcC7Zz oLZPZ22B5KaZX4zE56nOJUPho7HB2aosupbDonPKRpz5piuhsl3RoiVos1+6daIvMEUz RSz9AjI4OpdzfUC40+ZTGq7tUCP0kAxmTg0rE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=wtdecgnwipswkXfbi3EFi48NS1BuMm+EyqIarVkBsJRnvEOuw/nzql91xSiWqfSGuY zGS+c3Xv5mgIryMk1asRnckUYxLwmv6wuiX8YoryCKkYYwDrIq6/0WY/EAO4GfPRjB5y +796qxSKNmN7TTHQLmitnaCsbSpUdZGyO9Fww= MIME-Version: 1.0 Received: by 10.216.59.83 with SMTP id r61mr5139848wec.5.1307467926946; Tue, 07 Jun 2011 10:32:06 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.93.193 with HTTP; Tue, 7 Jun 2011 10:32:06 -0700 (PDT) Date: Tue, 7 Jun 2011 10:32:06 -0700 X-Google-Sender-Auth: -MoOa9Ifht_9j2d2cnlH_Kf5wKg Message-ID: From: mdf@FreeBSD.org To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Check for 0 ino_t in readdir(3) 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, 07 Jun 2011 17:32:08 -0000 There is a check in the function implementing readdir(3) for a zero inode number: struct dirent * _readdir_unlocked(dirp, skip) DIR *dirp; int skip; { /* ... */ if (dp->d_ino == 0 && skip) continue; /* ... */ } "skip" is 1 except for when coming from _seekdir(3). I don't recall any requirement that a filesystem not use an inode numbered 0, though for obvious reasons it's a poor choice for a file's inode. So... is this code in libc incorrect? Or is there documentation that 0 cannot be a valid inode number for a filesystem? If 0 cannot be a valid inode number, my GSoC mentee Gleb suggested d_fileno == 0 be skipped in dirent_exists() as used by vop_stdvptocnp(9), and also skipped by unionfs. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 19:57:40 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 454921065672 for ; Tue, 7 Jun 2011 19:57:40 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id BA4678FC1C for ; Tue, 7 Jun 2011 19:57:39 +0000 (UTC) Received: (qmail 27722 invoked by uid 0); 7 Jun 2011 19:57:38 -0000 Received: from 67.206.164.95 by rms-us001.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 07 Jun 2011 19:57:30 +0000 From: "Dieter BSD" Message-ID: <20110607195735.198110@gmx.com> MIME-Version: 1.0 To: hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: wPeHfi4D33erJQ7YAmtnnswjL0tsZo1L Cc: Subject: Testing a change to printf(9) 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, 07 Jun 2011 19:57:40 -0000 I've been working on fixing problems with printf(9), log(9) and related functions.  Today I tried converting printf(9) to write to the log rather than directly to the console, unless the log is not open, in which case the message is also sent to the console. Printf(...) is now the same as log(LOG_INFO, ...). I commented out the line in /etc/syslog.conf that sends some log messages to the console.  In multiuser mode, normal printfs go to log, but not the console, as expected. Bootup messages, shutdown messages, and panic messages all show up on the console as expected. Are there any other special cases to test? From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 21:17: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 11CB31065674; Tue, 7 Jun 2011 21:17:14 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id A7F5E8FC21; Tue, 7 Jun 2011 21:17:13 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 10FD41DD415; Tue, 7 Jun 2011 23:17:13 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 071BF173FD; Tue, 7 Jun 2011 23:17:13 +0200 (CEST) Date: Tue, 7 Jun 2011 23:17:12 +0200 From: Jilles Tjoelker To: Andrey Chernov , freebsd-hackers@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG Message-ID: <20110607211712.GA16994@stack.nl> References: <20110606224105.GA92410@stack.nl> <20110607002442.GA89483@vniz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110607002442.GA89483@vniz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: tr A-Z a-z in locales other than C 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, 07 Jun 2011 21:17:14 -0000 On Tue, Jun 07, 2011 at 04:24:43AM +0400, Andrey Chernov wrote: > On Tue, Jun 07, 2011 at 12:41:05AM +0200, Jilles Tjoelker wrote: > > There is a related issue with ranges in regular expressions, glob and > > fnmatch (likewise unspecified by POSIX outside the POSIX locale), but > > this is less likely to cause problems. > You care about ports, but suggested change is americano-centrism which > kills tr usage for national language documents due to impossibility to > specify whole national alphabet easily, just by two letters. Hmm, so that's with translation to a constant, or with the -d and/or -s options. In such cases, there may be a range for all letters with collation order, but not with codeset order (mainly if "all letters" includes letters with diacritical marks). In FreeBSD, upper case sorts before lower case, so cases can be distinguished this way but all letters may require two ranges. In most other operating systems the cases go together so a single range is sufficient, but cases cannot be distinguished. Making such things work on multiple operating systems requires careful testing. > Moreover, having differently treated regex ranges in tr vs other places > you mention will produce additional chaos. I think this is already inconsistent because some programs do not enable locale or use different locale code. With UTF-8 or other multibyte character sets, this is even more so because functions like isalpha work very poorly by definition and there is no collation support for such character sets in FreeBSD. > Back to the ports: it is not hard to run _any_ port's make or configure > with LANG=C directly by the ports Mk system to eliminate that problem. True, but some ports install scripts with problematic tr calls. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 22:08:04 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 8EB51106566C for ; Tue, 7 Jun 2011 22:08:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 64A178FC16 for ; Tue, 7 Jun 2011 22:08:04 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p57M7xxI025172 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Jun 2011 15:08:02 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DEEA13C.7040200@freebsd.org> Date: Tue, 07 Jun 2011 15:07:56 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dieter BSD References: <20110607195735.198110@gmx.com> In-Reply-To: <20110607195735.198110@gmx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Testing a change to printf(9) 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, 07 Jun 2011 22:08:04 -0000 On 6/7/11 12:57 PM, Dieter BSD wrote: > I've been working on fixing problems with printf(9), log(9) and > related functions. Today I tried converting printf(9) to write > to the log rather than directly to the console, unless the log is > not open, in which case the message is also sent to the console. > Printf(...) is now the same as log(LOG_INFO, ...). oh please no! from my perspective, I want my printf output to go to the console. immediately, regardless of where it goes after that. I don't care if there is or is not a log. I do NOT want to EVER have the problem I've had on linux where the last vital bit of output never made it out before the system stopped. once it's been shown on the console I don't care what happens to it.. > I commented out the line in /etc/syslog.conf that sends > some log messages to the console. In multiuser mode, > normal printfs go to log, but not the console, as expected. > > Bootup messages, shutdown messages, and panic messages all > show up on the console as expected. > > Are there any other special cases to test? > _______________________________________________ > 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 Tue Jun 7 22:23:24 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 17135106566C for ; Tue, 7 Jun 2011 22:23:24 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id D46178FC18 for ; Tue, 7 Jun 2011 22:23:23 +0000 (UTC) Received: (qmail 98971 invoked by uid 1000); 7 Jun 2011 21:56:42 -0000 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Date: Wed, 8 Jun 2011 09:56:39 +1200 (NZST) From: Atom Smasher In-Reply-To: <20110606224105.GA92410@stack.nl> Message-ID: <1106080945020.2239@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <20110606224105.GA92410@stack.nl> To: freebsd-hackers@freebsd.org X-POM: The Moon is Waxing Crescent (37% of Full) X-Hashcash: 1:20:1106072156:freebsd-hackers@freebsd.org::oAFr083FldiGMCkw:000000 0000000000000000000000000XyB X-Hashcash: 1:20:1106072156:freebsd-i18n@freebsd.org::q2DIAFaqBYjAk1RV:000000000 0000000000000000000000004Jzl Cc: freebsd-i18n@freebsd.org Subject: Re: tr A-Z a-z in locales other than C 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, 07 Jun 2011 22:23:24 -0000 the man page makes it clear... Translate the contents of file1 to upper-case. tr "[:lower:]" "[:upper:]" < file1 (This should be preferred over the traditional UNIX idiom of ``tr a-z A-Z'', since it works correctly in all locales.) for any other uses, either build the port with locale specified as "C" as mentioned, or patch the port so: tr '[a-z]' '[A-Z]' becomes: env LC_ALL=C tr '[a-z]' '[A-Z]' the only change that would be appropriate to the tr utility would be a command-line option to select a locale... something like: tr -l C '[a-z]' '[A-Z]' i don't think anyone would object to that, but it would still require patching some ports under some locales... maybe another option would be modifying tr to recognize other [new] environment variables... TR_LANG, TR_LC_ALL, TR_LC_CTYPE and TR_LC_COLLATE. done that way, things could be set in /etc/make.conf (or sys.mk), not need any patching, and not interfere with other uses of locale. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "We in the West must bear in mind that the poor countries are poor primarily because we have exploited them through political or economic colonialism." -- Martin Luther King, Jr From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 23:00:44 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 8613F106566C; Tue, 7 Jun 2011 23:00:44 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 287E78FC0C; Tue, 7 Jun 2011 23:00:44 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 27A8C1DD97B; Wed, 8 Jun 2011 01:00:43 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 100431753C; Wed, 8 Jun 2011 01:00:43 +0200 (CEST) Date: Wed, 8 Jun 2011 01:00:43 +0200 From: Jilles Tjoelker To: Atom Smasher Message-ID: <20110607230042.GB16994@stack.nl> References: <20110606224105.GA92410@stack.nl> <1106080945020.2239@smasher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1106080945020.2239@smasher> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, freebsd-i18n@freebsd.org Subject: Re: tr A-Z a-z in locales other than C 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, 07 Jun 2011 23:00:44 -0000 On Wed, Jun 08, 2011 at 09:56:39AM +1200, Atom Smasher wrote: > the man page makes it clear... > Translate the contents of file1 to upper-case. > tr "[:lower:]" "[:upper:]" < file1 > (This should be preferred over the traditional UNIX idiom of ``tr a-z > A-Z'', since it works correctly in all locales.) > for any other uses, either build the port with locale specified as "C" as > mentioned, or patch the port so: > tr '[a-z]' '[A-Z]' > becomes: > env LC_ALL=C tr '[a-z]' '[A-Z]' > the only change that would be appropriate to the tr utility would be a > command-line option to select a locale... something like: > tr -l C '[a-z]' '[A-Z]' > i don't think anyone would object to that, but it would still require > patching some ports under some locales... That new option would provide zero benefit. If things are going to be patched anyway then patch them to be standards compliant. > maybe another option would be modifying tr to recognize other [new] > environment variables... TR_LANG, TR_LC_ALL, TR_LC_CTYPE and > TR_LC_COLLATE. done that way, things could be set in /etc/make.conf (or > sys.mk), not need any patching, and not interfere with other uses of > locale. That would be rather ugly. If tr a-z A-Z is supposed to be deceiving in some locales, then let it remain so unconditionally. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 7 23:28:37 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 EF7461065672 for ; Tue, 7 Jun 2011 23:28:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5FB8FC14 for ; Tue, 7 Jun 2011 23:28:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwGACuz7k2DaFvO/2dsb2JhbABThEqTNI8itmOQfYErg2yBCgSRE4dZiA0 X-IronPort-AV: E=Sophos;i="4.65,335,1304308800"; d="scan'208";a="123249306" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Jun 2011 19:28:36 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B3EBDB3F20; Tue, 7 Jun 2011 19:28:36 -0400 (EDT) Date: Tue, 7 Jun 2011 19:28:36 -0400 (EDT) From: Rick Macklem To: mdf@FreeBSD.org Message-ID: <1936865111.251439.1307489316675.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers Subject: Re: Check for 0 ino_t in readdir(3) 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, 07 Jun 2011 23:28:38 -0000 mdf wrote: > There is a check in the function implementing readdir(3) for a zero > inode number: > > struct dirent * > _readdir_unlocked(dirp, skip) > DIR *dirp; > int skip; > { > /* ... */ > if (dp->d_ino == 0 && skip) > continue; > /* ... */ > } > > "skip" is 1 except for when coming from _seekdir(3). > > I don't recall any requirement that a filesystem not use an inode > numbered 0, though for obvious reasons it's a poor choice for a file's > inode. So... is this code in libc incorrect? Or is there > documentation that 0 cannot be a valid inode number for a filesystem? > Well, my recollection (if I'm incorrect, please correct me:-) is that, for real BSD directories (the ones generated by UFS/FFS, which everything else is expected to emulate), the d_ino field is set to 0 when the first entry in a directory block is unlink'd. This is because directory entries are not permitted to straddle blocks, so the first entry can not be subsumed by the last dirent in the previous block. In other words, when d_ino == 0, the dirent is free. rick From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 01:25:08 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 D3781106566B for ; Wed, 8 Jun 2011 01:25:08 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6521D8FC0A for ; Wed, 8 Jun 2011 01:25:08 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QU7W5-0002qx-BX for freebsd-hackers@freebsd.org; Wed, 08 Jun 2011 03:25:05 +0200 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2011 03:25:05 +0200 Received: from johannes by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2011 03:25:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Johannes Totz Date: Wed, 08 Jun 2011 02:23:48 +0100 Lines: 36 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 In-Reply-To: Subject: Re: sizeof(function pointer) 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, 08 Jun 2011 01:25:08 -0000 On 01/06/2011 00:07, mdf@FreeBSD.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds > drains to sbufs. The reason for MFC is that several pieces of new > code in CURRENT are using the drain functionality and it would make > MFCing those changes much easier. > > The problem is that r212367 added a pointer to a drain function in the > sbuf (it replaced a pointer to void). The C standard doesn't > guarantee that a void * and a function pointer have the same size, > though its true on amd64, i386 and I believe PPC. What I'm wondering > is, though not guaranteed by the standard, is it *practically* true > that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't > break binary compatibility for any supported architecture? (The > standard does guarantee, though not in words, that all function > pointers have the same size, since it guarantees that pointers to > functions can be cast to other pointers to functions and back without > changing the value). > > Another possibility is to malloc a blob that is sizeof(int(*)(void)) > and store that in a renamed s_unused; this is a bit messier but > guaranteed to work. I'd just rather the code be an MCF instead of a > partial re-write. You could add a static-assert to check for this at compile-time: http://stackoverflow.com/questions/3385515/static-assert-in-c e.g. something like: STATIC_ASSERT(sizeof(void *) == sizeof(int(*)(void)),ptr_to_func_expected_to_be_same_size_as_data_ptr); I've only used static-assert-like constructs in C++, so don't know how well they behave in C... -- Sent from my From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 01:33:53 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 D62F7106564A for ; Wed, 8 Jun 2011 01:33:53 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 55D488FC12 for ; Wed, 8 Jun 2011 01:33:53 +0000 (UTC) Received: (qmail 10286 invoked by uid 0); 8 Jun 2011 01:33:51 -0000 Received: from 67.206.164.132 by rms-us006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 08 Jun 2011 01:33:48 +0000 From: "Dieter BSD" Message-ID: <20110608013350.111860@gmx.com> MIME-Version: 1.0 To: hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: GLWGAIlKymCuIg6GUjA0mn8iJihyapAR Cc: Subject: Re: Testing a change to printf(9) 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, 08 Jun 2011 01:33:53 -0000 >> I've been working on fixing problems with printf(9), log(9) and >> related functions. Today I tried converting printf(9) to write >> to the log rather than directly to the console, unless the log is >> not open, in which case the message is also sent to the console. >> Printf(...) is now the same as log(LOG_INFO, ...). > oh please no! > > from my perspective, I want my printf output to go to the console. > immediately, regardless of where it goes after that. > I don't care if there is or is not a log. > I do NOT want to EVER have the problem I've had on linux where > the last vital bit of output never made it out before the system stopped. > > once it's been shown on the console I don't care what happens to it.. Printfs to the console cause data loss. Easily repeatable. Absolutely unacceptable. You are welcome to fix the actual underlying problem. I would love to see the underlying problem fixed! I've asked a few times before, but I'll ask again. Why does a driver for one piece of hardware have to block interrupts for all hardware? I thought changing from spl to mutex was supposed to fix this? My changes do not prevent a sysadmin from having printf output go to the console, it gives them a choice. Currently there is no choice. >> I commented out the line in /etc/syslog.conf that sends >> some log messages to the console. In multiuser mode, >> normal printfs go to log, but not the console, as expected. >> >> Bootup messages, shutdown messages, and panic messages all >> show up on the console as expected. >> >> Are there any other special cases to test? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 01:51:54 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 4EF721065676 for ; Wed, 8 Jun 2011 01:51:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA158FC0C for ; Wed, 8 Jun 2011 01:51:53 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p581pn61025776 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Jun 2011 18:51:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DEED5B2.5050802@freebsd.org> Date: Tue, 07 Jun 2011 18:51:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dieter BSD References: <20110608013350.111860@gmx.com> In-Reply-To: <20110608013350.111860@gmx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Testing a change to printf(9) 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, 08 Jun 2011 01:51:54 -0000 On 6/7/11 6:33 PM, Dieter BSD wrote: >>> I've been working on fixing problems with printf(9), log(9) and >>> related functions. Today I tried converting printf(9) to write >>> to the log rather than directly to the console, unless the log is >>> not open, in which case the message is also sent to the console. >>> Printf(...) is now the same as log(LOG_INFO, ...). >> oh please no! >> >> from my perspective, I want my printf output to go to the console. >> immediately, regardless of where it goes after that. >> I don't care if there is or is not a log. >> I do NOT want to EVER have the problem I've had on linux where >> the last vital bit of output never made it out before the system stopped. >> >> once it's been shown on the console I don't care what happens to it.. > Printfs to the console cause data loss. Easily repeatable. > Absolutely unacceptable. > > You are welcome to fix the actual underlying problem. I would > love to see the underlying problem fixed! I've asked a few times > before, but I'll ask again. Why does a driver for one piece of > hardware have to block interrupts for all hardware? I thought > changing from spl to mutex was supposed to fix this? > > My changes do not prevent a sysadmin from having printf output > go to the console, it gives them a choice. Currently there is > no choice. NO! a kernel printf goes to the console however it may be redirected. It MAY also decide to go somewhere else. But not if it means unreliable delivery to the serial port. The console MUST get the output in a completely reliable manner unless it's been disabled. do not do anything that gets between the console and the problem. if you want to send it on to some other secondary sevice such s a log, then disable the console and take the priority service but do NOT do any of the silly tricks that some people have tried in the past like making the console just one of several things on a mux. all with equal ability to screw up the other. I want the console to be the last refuge in a dying system. if a send a char there I KNOW it's gone out. it is synchronous and it doesn't lie. if you don't want a reliable console then turn it off but don't make something else that is unreliable and call it the console. call it anything else but don't screw up the console. >>> I commented out the line in /etc/syslog.conf that sends >>> some log messages to the console. In multiuser mode, >>> normal printfs go to log, but not the console, as expected. >>> >>> Bootup messages, shutdown messages, and panic messages all >>> show up on the console as expected. >>> >>> Are there any other special cases to test? > _______________________________________________ > 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 Wed Jun 8 03:06:50 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 D290C106566B for ; Wed, 8 Jun 2011 03:06:50 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id 9AC278FC18 for ; Wed, 8 Jun 2011 03:06:50 +0000 (UTC) Received: (qmail 78634 invoked by uid 1000); 8 Jun 2011 03:06:50 -0000 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Wed, 8 Jun 2011 15:06:46 +1200 (NZST) From: Atom Smasher In-Reply-To: <20110607230042.GB16994@stack.nl> Message-ID: <1106081505190.2239@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <20110606224105.GA92410@stack.nl> <1106080945020.2239@smasher> <20110607230042.GB16994@stack.nl> To: freebsd-hackers@freebsd.org X-POM: The Moon is Waxing Crescent (40% of Full) X-Hashcash: 1:20:1106080306:freebsd-hackers@freebsd.org::0SUWRzFDEIdHn3C+:000000 0000000000000000000000006iB6 X-Hashcash: 1:20:1106080306:freebsd-i18n@freebsd.org::HoAlcUVBQxC/+3Wx:000000000 0000000000000000000000004F0W Cc: freebsd-i18n@freebsd.org Subject: Re: tr A-Z a-z in locales other than C 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, 08 Jun 2011 03:06:50 -0000 On Wed, 8 Jun 2011, Jilles Tjoelker wrote: >> maybe another option would be modifying tr to recognize other [new] >> environment variables... TR_LANG, TR_LC_ALL, TR_LC_CTYPE and >> TR_LC_COLLATE. done that way, things could be set in /etc/make.conf (or >> sys.mk), not need any patching, and not interfere with other uses of >> locale. > > That would be rather ugly. > > If tr a-z A-Z is supposed to be deceiving in some locales, then let it > remain so unconditionally. ================= it can still be as ugly as one wants it to be, and in some ports that might be fine. but this option would provide a very simple option to reign in how ugly it is. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "The livestock sector is a major player [in climate change], responsible for 18% of greenhouse gas emissions measured in CO2 equivalent. This is a higher share than transport." -- Livestock's long shadow, 2006 UN report sponsored by WTO, EU, AS-AID, FAO, et al From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 03:25:09 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 21C5A106566B; Wed, 8 Jun 2011 03:25:09 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7DABD8FC14; Wed, 8 Jun 2011 03:25:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.4/8.14.4) with ESMTP id p583P66x011239; Wed, 8 Jun 2011 07:25:06 +0400 (MSD) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.4/8.14.4/Submit) id p583P6oI011238; Wed, 8 Jun 2011 07:25:06 +0400 (MSD) (envelope-from ache) Date: Wed, 8 Jun 2011 07:25:06 +0400 From: Andrey Chernov To: Jilles Tjoelker Message-ID: <20110608032506.GA11098@vniz.net> Mail-Followup-To: Andrey Chernov , Jilles Tjoelker , freebsd-hackers@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG References: <20110606224105.GA92410@stack.nl> <20110607002442.GA89483@vniz.net> <20110607211712.GA16994@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110607211712.GA16994@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-i18n@FreeBSD.ORG Subject: Re: tr A-Z a-z in locales other than C 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, 08 Jun 2011 03:25:09 -0000 On Tue, Jun 07, 2011 at 11:17:12PM +0200, Jilles Tjoelker wrote: > In FreeBSD, upper case sorts before lower case, so cases can be > distinguished this way but all letters may require two ranges. In most > other operating systems the cases go together so a single range is > sufficient, but cases cannot be distinguished. Making such things work > on multiple operating systems requires careful testing. Such thing can't work consistenly on multiple operating systems by definition, because POSIX states "undefined" here. So the best we can is to concentrace on our system. No program should relay on that until POSIX define that somehow. > > Moreover, having differently treated regex ranges in tr vs other places > > you mention will produce additional chaos. > > I think this is already inconsistent because some programs do not enable > locale or use different locale code. I say the same, producing additional chaos is not bringing chaos from nowhere. AFAIK nobody use different locale code but often different regex implemetation. > > Back to the ports: it is not hard to run _any_ port's make or configure > > with LANG=C directly by the ports Mk system to eliminate that problem. > > True, but some ports install scripts with problematic tr calls. What count says, how many ports do that? Summarizing I suggest to consider two models: 1) Developer/programer etc. tr coderange does good for it. 2) Working with national language docs/end user/ tr coderange does bad for it. Sacrificing model 2) for 1) is not the thing we need, if such ports number is low. If such ports number is significant, we can consider additional options like automatically search and replace such tr's through pkg-plist (similar scanning we already do for security reasons). -- http://ache.vniz.net/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 04:24:56 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 B7BBA106566C; Wed, 8 Jun 2011 04:24:56 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 77E5B8FC1B; Wed, 8 Jun 2011 04:24:56 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p584OsWt067047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 21:24:54 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p584OsRd067046; Tue, 7 Jun 2011 21:24:54 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01248; Tue, 7 Jun 11 21:12:42 PDT Date: Tue, 07 Jun 2011 21:12:37 -0700 From: perryh@pluto.rain.com To: jilles@stack.nl Message-Id: <4deef6b5.i/YJyk4lV85AhCTM%perryh@pluto.rain.com> References: <20110606224105.GA92410@stack.nl> <20110607002442.GA89483@vniz.net> <20110607211712.GA16994@stack.nl> In-Reply-To: <20110607211712.GA16994@stack.nl> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, ache@freebsd.org, freebsd-i18n@freebsd.org Subject: Re: tr A-Z a-z in locales other than C 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, 08 Jun 2011 04:24:56 -0000 Jilles Tjoelker wrote: > On Tue, Jun 07, 2011 at 04:24:43AM +0400, Andrey Chernov wrote: ... > > Back to the ports: it is not hard to run _any_ port's make > > or configure with LANG=C directly by the ports Mk system to > > eliminate that problem. > > True, but some ports install scripts with problematic tr calls. So part of the porting effort may be to provide a patch that prepends something along the lines of "env LANG=C" to tr calls in those scripts. It would surely not be the only kind of situation in which a port needed to patch the ported code to get it to run correctly on FreeBSD :) From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 07:51:57 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 15FF9106566C; Wed, 8 Jun 2011 07:51:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C47DC8FC13; Wed, 8 Jun 2011 07:51:56 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QUDAb-000CpB-OD; Wed, 08 Jun 2011 10:27:18 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Julian Elischer In-reply-to: <4DEED5B2.5050802@freebsd.org> References: <20110608013350.111860@gmx.com> <4DEED5B2.5050802@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Tue, 07 Jun 2011 18:51:46 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Jun 2011 10:27:17 +0300 From: Daniel Braniss Message-ID: Cc: hackers@freebsd.org, Dieter BSD Subject: Re: Testing a change to printf(9) 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, 08 Jun 2011 07:51:57 -0000 > On 6/7/11 6:33 PM, Dieter BSD wrote: > >>> I've been working on fixing problems with printf(9), log(9) and > >>> related functions. Today I tried converting printf(9) to write > >>> to the log rather than directly to the console, unless the log is > >>> not open, in which case the message is also sent to the console. > >>> Printf(...) is now the same as log(LOG_INFO, ...). > >> oh please no! > >> > >> from my perspective, I want my printf output to go to the console. > >> immediately, regardless of where it goes after that. > >> I don't care if there is or is not a log. > >> I do NOT want to EVER have the problem I've had on linux where > >> the last vital bit of output never made it out before the system stopped. > >> > >> once it's been shown on the console I don't care what happens to it.. > > Printfs to the console cause data loss. Easily repeatable. > > Absolutely unacceptable. > > > > You are welcome to fix the actual underlying problem. I would > > love to see the underlying problem fixed! I've asked a few times > > before, but I'll ask again. Why does a driver for one piece of > > hardware have to block interrupts for all hardware? I thought > > changing from spl to mutex was supposed to fix this? > > > > My changes do not prevent a sysadmin from having printf output > > go to the console, it gives them a choice. Currently there is > > no choice. > NO! a kernel printf goes to the console however it may be redirected. I agree 100%! file system full ... > It MAY also decide to go somewhere else. > But not if it means unreliable delivery to the serial port. > The console MUST get the output in a completely reliable manner unless > it's been disabled. > do not do anything that gets between the console and the problem. > if you want to send it on to some other secondary sevice such s a log, > then disable the console and take the priority service but do NOT do > any of the silly tricks that some people have tried in the past like > making the console just one of several things on a mux. all with equal > ability to screw up the other. I want the console to be the last > refuge in a dying system. > if a send a char there I KNOW it's gone out. it is synchronous and it > doesn't lie. > if you don't want a reliable console then turn it off but don't make > something else that is unreliable and call it the console. > call it anything else but don't screw up the console. > > > > > >>> I commented out the line in /etc/syslog.conf that sends > >>> some log messages to the console. In multiuser mode, > >>> normal printfs go to log, but not the console, as expected. > >>> > >>> Bootup messages, shutdown messages, and panic messages all > >>> show up on the console as expected. > >>> > >>> Are there any other special cases to test? > > _______________________________________________ > > 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" > > > > > > _______________________________________________ > 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 Wed Jun 8 17:51:52 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 411F81065670 for ; Wed, 8 Jun 2011 17:51:52 +0000 (UTC) (envelope-from rank1seeker@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 C72098FC12 for ; Wed, 8 Jun 2011 17:51:51 +0000 (UTC) Received: by wwc33 with SMTP id 33so825244wwc.31 for ; Wed, 08 Jun 2011 10:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=OF43SNIs1c8RHlvve+gJcvy0ckO+DXF5j4S0h0Cc0TA=; b=m5J6ShRQswYqQqRp3XS4sZJ/A63NbgN5hqLk8Z+b8BY6p1DlZdVGaJEfjNm0vduac1 Cpv009uDxjZxavfAy+rM6AAkVa/Xf6UCmrmK00kvtjzq41NJYSNq7V4d//LR61CExc+g EeSYREnu5U0kZ1kLzQCYUT9b/fbB6clpX6qKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; b=DD5KAKKubqw2xH4qSI5jjGe2T/HDnIExa1CKOazpyrvxC6FV4nJod/PbIGmD8J/vDh XOEpiQiyGJwnP3ksI9eRBlx1LRKrO/Xb6kguOUs/63w4ZncxRUwa5d56De3dy2J7+jAr /FR8+KgIalRLffxBbMqrOUeAQmFzfzT7HkVhM= Received: by 10.216.242.205 with SMTP id i55mr5601845wer.66.1307554772880; Wed, 08 Jun 2011 10:39:32 -0700 (PDT) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id fm14sm584755wbb.58.2011.06.08.10.39.28 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 10:39:31 -0700 (PDT) Message-ID: <20110608.173928.921.1@DEV> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Wed, 08 Jun 2011 19:39:28 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <20110607002442.GA89483@vniz.net> References: <20110606224105.GA92410@stack.nl> <20110607002442.GA89483@vniz.net> X-Mailer: POP Peeper (3.7.0.0) Cc: Subject: BUG: Targets 'config-recursive' and 'config-conditional', behave same! 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, 08 Jun 2011 17:51:52 -0000 http://forums.freebsd.org/showthread.php?p=3D136894=0D=0A=0D=0AWhat do you = think?=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 9 19:32: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 CF5D5106566C for ; Thu, 9 Jun 2011 19:32:18 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6238C8FC0A for ; Thu, 9 Jun 2011 19:32:17 +0000 (UTC) Received: by eyg7 with SMTP id 7so946507eyg.13 for ; Thu, 09 Jun 2011 12:32:17 -0700 (PDT) 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=OrkQmwImWXh18m1TNKLlKgWZ7lLko1u1AlqkmigFNEM=; b=JeSq8kjMd2KE4ni9ivNjnXvkHLXEddLu+7nroCEZM+DTWmxCNI7SkGHn1Ww6dwSFgr pbjHDyb3RoKMhcVc2UifEJ+HDlD6DRPsLGIweDQU2rGl5n/U4iTflPIATLtZTsSfIhFz /t1XYhY9RVoGxD/zTZqS1uxn+IEVLKdLEYxdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EWGBSEWM8bzI7aV5NzW5EELxqAqWaUbpffxSR/rGRD26sgZODp2GRbeX1jYM2vYza5 i7KR2i/EDY+stmI9B5NovRsdrSJsBx1rkpvq6DqIAZrJJGZlxf7NT7wvYa8CWQidSINr /Ek4OSDcR92vMhWGxf9pdE1SRRK+X2anYlGrE= MIME-Version: 1.0 Received: by 10.213.33.5 with SMTP id f5mr2772124ebd.82.1307646612923; Thu, 09 Jun 2011 12:10:12 -0700 (PDT) Received: by 10.213.26.17 with HTTP; Thu, 9 Jun 2011 12:10:12 -0700 (PDT) Date: Thu, 9 Jun 2011 15:10:12 -0400 Message-ID: From: Ryan Stone To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Large data segments interact poorly with MALLOC_OPTIONS=M 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, 09 Jun 2011 19:32:18 -0000 At $(WORK) I've been porting our applications from FreeBSD 6 to FreeBSD 8. One of our daemons tends to be a big memory hog, so we set a data segment size of 1.5GB to accommodate it. This ends up breaking horribly now that malloc uses mmap to allocate memory by default. What happens is that malloc ends up exhausting all of the address space outside of the data segment first(with mmap) before using any of the data segment(with sbrk). Meanwhile, other users of mmap can only allocate address space outside of the data segment. This includes pthread_create, which allocates the thread's stack directly via mmap. Is the recommendation with jemalloc to make the data segment as small as possible, to avoid these types of issues? From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 9 20:27: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 1CDDB106564A; Thu, 9 Jun 2011 20:27:55 +0000 (UTC) (envelope-from kc5vdj.freebsd@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 CA1FE8FC0C; Thu, 9 Jun 2011 20:27:54 +0000 (UTC) Received: by iwn33 with SMTP id 33so2351685iwn.13 for ; Thu, 09 Jun 2011 13:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=8I2N3K3lfAiV5eGwU6j4dMSAIf+2AIfhX1fy8yET7k4=; b=is7WcQAlKLfblxzAD3HMBflDj0khhhC5BBNHmn+yLcZ5QFoxWtNYwHy+KnDcWVIDJX bUsj13bk0Cmj1JlviPdMNhVszYnNvyDhD3q3BdFU/FC983sJf0O0BbGYS8dHHPjRvVwj WMy3YioSle+cTGd+T7rVtcKB3kLQAdOg5RKc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=s6gBsDQg8CBi8W1EYcBYT1ofAwTvwmP6BnY3Zw1VCG0b//mXEx5qUoo3HtNxtJpSQr d9GWI0y8o2LWxfnBm3hIqTs6CmX9NNQ7ox/98e4a0RB1fajHTuvatouiTLJyP3Zzb/yj BpFNTOcWGmY5Q/Nhbh0/k+8cPCFWEYMiW/R0g= Received: by 10.231.44.65 with SMTP id z1mr1418360ibe.95.1307649729183; Thu, 09 Jun 2011 13:02:09 -0700 (PDT) Received: from argus.electron-tube.net (desm-45-047.dsl.netins.net [167.142.45.47]) by mx.google.com with ESMTPS id w8sm926520ibh.52.2011.06.09.13.02.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2011 13:02:08 -0700 (PDT) Message-ID: <4DF126B5.8040800@gmail.com> Date: Thu, 09 Jun 2011 15:01:57 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: kvm_open errors on /proc/*/mem in top 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, 09 Jun 2011 20:27:55 -0000 i'm not sure which list this belongs to, so i'm posting to -hackers and -stable. i've noticed for a while now that during heavy activity (for instance buildworld), that top will get these kvm_read errors when reading proc mem entries. i have included a screenshot of what happens during such events... last pid: 92024; load averages: 4.79, 4.58, 4.10 up 0+00:49:07 15:30:53 225 processes: 10 running, 197 sleeping, 18 waiting CPU: 90.6% user, 0.0% nice, 9.4% system, 0.0% interrupt, 0.0% idle Mem: 493M Active, 1337M Inact, 604M Wired, 632K Cache, 315M Buf, 524M Free Swap: 4097M Total, 4097M Free kvm_open: cannot open /proc/86755/mem PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 91943 root 1 97 0 39536K 33620K RUN 1 0:01 7.37% [cc1plus] 2859 jbryant 1 48 0 406M 72332K select 0 3:10 5.96% kwin -session 1028b2382461f5000127042056000000019550000_13 2747 root 1 46 0 419M 370M select 0 1:43 4.39% /usr/local/bin/X :0 -nolisten tcp -auth /var/run/xauth/A:0 1464 root 1 44 0 8068K 1384K select 0 0:03 0.39% /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.u 11219 jbryant 7 44 0 299M 109M select 1 0:17 0.29% /usr/local/lib/thunderbird/thunderbird-bin 2865 jbryant 1 45 0 453M 86140K select 0 0:21 0.20% kdeinit4: kdeinit4: plasma-desktop (kdeinit4) 2882 jbryant 1 44 0 391M 60996K select 0 0:17 0.10% kdeinit4: kdeinit4: kmix -session 102511e52251c60001304471 92001 root 1 97 0 23452K 22256K CPU1 1 0:00 0.00% [cc1] 92017 root 1 96 0 16172K 13440K RUN 0 0:00 0.00% [cc1] and such as this: last pid: 19348; load averages: 1.03, 1.93, 2.84 up 1+04:42:07 15:31:37 201 processes: 4 running, 178 sleeping, 19 waiting CPU: 47.4% user, 0.0% nice, 3.4% system, 0.0% interrupt, 49.3% idle Mem: 318M Active, 2400M Inact, 679M Wired, 1948K Cache, 407M Buf, 428M Free Swap: 8192M Total, 6488K Used, 8186M Free kvm_open: cannot open /proc/1141/memm kvm_open: cannot open /proc/92606/mem RES STATE C TIME WCPU COMMAND 10 root 2 171 ki31 0K 32K RUN 0 55.9H 103.81% [idle] 19344 root 1 96 0 17188K 14300K CPU1 0 0:00 0.00% [cc1] 19341 root 1 76 0 3204K 1068K select 1 0:00 0.00% make all DIRPRFX=fdc/ 19342 root 1 76 0 8340K 1848K wait 1 0:00 0.00% sh -ev 19343 root 1 76 0 3204K 596K wait 0 0:00 0.00% [cc] 19345 root 1 76 0 3204K 1292K piperd 0 0:00 0.00% /usr/obj/usr/src/tmp/usr/bin/as -Qy -o fdc.o the current fix for this is to [CTRL]-L. i assume that what is happening is that top just loosing track of what's running, and the procs are dead by the time it tries to read them, or that the proc ends during top reading. is there any way to fix this? it's annoying as f&#k. ps: running 8-STABLE. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 9 20:46:52 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 28378106564A; Thu, 9 Jun 2011 20:46:52 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id EBF8C8FC16; Thu, 9 Jun 2011 20:46:51 +0000 (UTC) Received: by pxi6 with SMTP id 6so1135601pxi.17 for ; Thu, 09 Jun 2011 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=bmfN86UPLnthtn/heyx+h1oZHUXGV2Er5w9JaE8xzJ0=; b=CTPI3z6hJhyCLRdrGOV7bJ0GfhL4a2oBk/Qd7Rh8rE0YdX8ZlGxxkZZ5JgiUXLdt28 oBNJLBssZ9Ld7qzBHSF9K5Ja1QCvP8CHqK8Ct6Hu00BdByyjZMIc/L+/2SJFehkInJKd UW/ygp2Gp31DcgYa2v8vWcGB3sPhkIEvJGgcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=LNnrDGkzyBSts9Nf5my9kEMbrdAYsZ7GZT/QWEOk00lRMhaO5KB101opzu2Pv21Bcx hVAQCSh+O6skr9BIqaIUy99W/Umahr+7R9HRMa4y617QIDvPF/87ebvosVC0xwXmMo/m eJfeIwaoVCJ1HEuoRoUKH9CZBef8alblZmggk= MIME-Version: 1.0 Received: by 10.68.24.37 with SMTP id r5mr535118pbf.450.1307650515075; Thu, 09 Jun 2011 13:15:15 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.68.51.9 with HTTP; Thu, 9 Jun 2011 13:15:14 -0700 (PDT) Date: Thu, 9 Jun 2011 23:15:14 +0300 X-Google-Sender-Auth: bFankaoD9cfNGEvX62cAc7uvaMU Message-ID: From: Mohammed Farrag To: freebsd-hackers@freebsd.org, freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD extended to Arab World 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, 09 Jun 2011 20:46:52 -0000 Hi Community, First I introduce myself, Mohammed Farrag, ArabBSD Project Manager and FreeBSD Contributor. We have a project to extend FreeBSD in Arab world. We aim to work in two direction. First, we will translate FreeBSD Documentation and learning tutorials to Arabic. Second, we will have summer training for starting work on FreeBSD development. Our website is https://sites.google.com/site/arabbsd/ and our facebook group is http://www.facebook.com/home.php?sk=group_114438501975285&ap=1 I will be glad to receive your comments/ and recommendations. Regards, -- *Mohammed Farrag* From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 9 23:53:16 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 2C864106564A for ; Thu, 9 Jun 2011 23:53:16 +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 16B178FC08 for ; Thu, 9 Jun 2011 23:53:15 +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 p59Nqxqi027282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Jun 2011 16:53:15 -0700 (PDT) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Jun 2011 16:53:15 -0700 Message-Id: <770F46B2-1EB5-4347-A0F7-6A041CC787FE@usenix.org> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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: Fri, 10 Jun 2011 00:12:06 +0000 Subject: USENIX TaPP '11 Program 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: Thu, 09 Jun 2011 23:53:16 -0000 We'd like to invite to join us in Crete, June 20-21, 2011, for the 3rd USENIX Workshop on the Theory and Practice of Provenance (TaPP '11). 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 program includes 29 technical papers representing some of the outstanding work in the area. Please note: unlike previous years, we will have the papers within discussion sessions. We have selected 10 broad sub-areas of provenance research, and for each we will have a tutorial followed by a short (5-minute) overview of papers that are related to the sub-area. The topics include: * Tutorial: Provenance and Causality * Provenance Models * Provenance in the Wild * Provenance Exchange, Integration, and Querying * Provenance Analytics * Tutorial: Provenance-Rich Publications * Security and Privacy * Provenance and Archiving * Annotation Algebras * Do people want provenance and are they prepared to pay for it? The full program is available at http://www.usenix.org/tapp11/proga TaPP '11 promises to be an exciting workshop showcasing serious cross-disciplinary, foundational, and highly speculative research. We hope you will join us in Crete. On behalf of the TaPP '11 Program Committee, Peter Buneman, University of Edinburgh Juliana Freire, University of Utah tapp11chairs@usenix.org P.S. TaPP '11 will be held the week after the meeting of ACM SIGMOD in Athens: http://www.sigmod2011.org/ ------------------------------------------------------------------ 3rd USENIX Workshop on the Theory and Practice of Provenance (TaPP '11) Sponsored by USENIX in cooperation with ACM SIGMOD, ACM SIGPLAN, and the W3C Greece Office June 20-21, 2011, Heraklion, Crete, Greece http://www.usenix.org/tapp11/proga From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 10 12:14:10 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 E6682106566C for ; Fri, 10 Jun 2011 12:14:10 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id B44AF8FC0A for ; Fri, 10 Jun 2011 12:14:10 +0000 (UTC) Received: (qmail 6928 invoked by uid 1000); 10 Jun 2011 12:14:10 -0000 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Date: Sat, 11 Jun 2011 00:14:08 +1200 (NZST) From: Atom Smasher Message-ID: <1106102346110.1931@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt To: freebsd-hackers@freebsd.org X-POM: The Moon is Waxing Gibbous (67% of Full) X-Hashcash: 1:20:1106101214:freebsd-hackers@freebsd.org::Mhs1EAkFIfBdueGX:000000 00000000000000000000000019Cs Subject: freebsd under qemu - slow 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, 10 Jun 2011 12:14:11 -0000 new laptop: LENOVO, 4313CTO, ThinkPad T510 Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz Integrated Graphics Chipset: Intel(R) Arrandale 4G RAM (DDR3-10600) old laptop: Acer, Navarro, Aspire 5100 AMD Turion(tm) 64 Mobile Technology MK-36 1995.02-MHz 2.5G RAM apparently video on freebsd isn't yet working out with the Arrandale, so i'm running ubuntu on the newer laptop and trying to get freebsd running under qemu. it's working, but it's painfully slow. a few CPU benchmarks show my old laptop running ten times faster!!! CPU benchmarks between ubuntu on the new hardware and freebsd on the old hardware, ubuntu is running about twice as fast. i'd hope to get freebsd/qemu running at least as fast as the old hardware. am i doing something wrong, or is this as good as it gets? -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "There is growing evidence that smoking has pharmacological effects that are of real value to smokers." -- Joseph F. Cullman III, President of Philip Morris, Annual Report to Stockholders, 1962 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 10 13:20: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 DBCEC106566B for ; Fri, 10 Jun 2011 13:20:57 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3E88FC0A for ; Fri, 10 Jun 2011 13:20:57 +0000 (UTC) Received: by qwc9 with SMTP id 9so1771601qwc.13 for ; Fri, 10 Jun 2011 06:20:56 -0700 (PDT) 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=TyXY3xZwbxsjV/La3Ewl7APdwH0jbP+FnIymO8BC8H8=; b=jDWB1OOlQHoGeLvTNnPIJvBhft5L3Wy85iXwY7ZXivBJUY/VpjMZXUVLlVhau/itsX 7bGIyOKCizVTZcZAa7VbmMITuO7sWHA3ASKbhs5g4NmHkqzJiBXThplcKNQF36aZkhK/ FKNvLxym387tb5NxDcPxpywwgYajKRNKjjYv4= 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=Fv5bQ8nk4twOF7RxQ+Wa8CHvZuqBLHoYNRrFQxSsAgHEd7VGBbJs+J54fizpa1PMsa uVoB1Z709vo/nJbw0D7hE47lrEMOMkhDsPJ/lbNKZpzcuPYMZLtWs75TeG+nGTaDGe7I Mnvjs6QF8RSGoHF/XwyHwIQJ8xnEGYU0JzrcI= MIME-Version: 1.0 Received: by 10.229.43.99 with SMTP id v35mr1576264qce.8.1307712056510; Fri, 10 Jun 2011 06:20:56 -0700 (PDT) Received: by 10.229.99.197 with HTTP; Fri, 10 Jun 2011 06:20:56 -0700 (PDT) In-Reply-To: <4DF126B5.8040800@gmail.com> References: <4DF126B5.8040800@gmail.com> Date: Fri, 10 Jun 2011 17:20:56 +0400 Message-ID: From: Sergey Kandaurov To: Jim Bryant Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kvm_open errors on /proc/*/mem in top 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, 10 Jun 2011 13:20:58 -0000 On 10 June 2011 00:01, Jim Bryant wrote: > i'm not sure which list this belongs to, so i'm posting to -hackers and > -stable. > > i've noticed for a while now that during heavy activity (for instance > buildworld), that top will get these kvm_read errors when reading proc > mem entries. Hi. I think that is a question of whether it's acceptable to hide all errors originated in kvm(3): Index: usr.bin/top/machine.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.bin/top/machine.c (revision 222893) +++ usr.bin/top/machine.c (working copy) @@ -265,7 +265,7 @@ else if (namelength > UPUNAMELEN) namelength =3D UPUNAMELEN; - kd =3D kvm_open(NULL, _PATH_DEVNULL, NULL, O_RDONLY, "kvm_open"); + kd =3D kvm_open(NULL, _PATH_DEVNULL, NULL, O_RDONLY, NULL); if (kd =3D=3D NULL) return (-1); Or rewrite top(1) a little more to open kvm with kvm_openfiles(), to let the caller decide itself in what places it needs to print an error with kvm_geterr(). > > i have included a screenshot of what happens during such events... > > last pid: 92024; =A0load averages: =A04.79, =A04.58, > 4.10 > up 0+00:49:07 =A015:30:53 > 225 processes: 10 running, 197 sleeping, 18 waiting > CPU: 90.6% user, =A00.0% nice, =A09.4% system, =A00.0% interrupt, =A00.0%= idle > Mem: 493M Active, 1337M Inact, 604M Wired, 632K Cache, 315M Buf, 524M Fre= e > Swap: 4097M Total, 4097M Free > kvm_open: cannot open /proc/86755/mem > =A0PID USERNAME =A0 =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 T= IME =A0 WCPU COMMAND > 91943 root =A0 =A0 =A0 =A0 =A01 =A097 =A0 =A00 39536K 33620K RUN =A0 =A0 = 1 =A0 0:01 =A07.37% > [cc1plus] > 2859 jbryant =A0 =A0 =A0 1 =A048 =A0 =A00 =A0 406M 72332K select =A00 =A0= 3:10 =A05.96% > kwin -session 1028b2382461f5000127042056000000019550000_13 > 2747 root =A0 =A0 =A0 =A0 =A01 =A046 =A0 =A00 =A0 419M =A0 370M select = =A00 =A0 1:43 =A04.39% > /usr/local/bin/X :0 -nolisten tcp -auth /var/run/xauth/A:0 > 1464 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A08068K =A01384K select = =A00 =A0 0:03 =A00.39% > /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.u > 11219 jbryant =A0 =A0 =A0 7 =A044 =A0 =A00 =A0 299M =A0 109M select =A01 = =A0 0:17 =A00.29% > /usr/local/lib/thunderbird/thunderbird-bin > 2865 jbryant =A0 =A0 =A0 1 =A045 =A0 =A00 =A0 453M 86140K select =A00 =A0= 0:21 =A00.20% > kdeinit4: kdeinit4: plasma-desktop (kdeinit4) > 2882 jbryant =A0 =A0 =A0 1 =A044 =A0 =A00 =A0 391M 60996K select =A00 =A0= 0:17 =A00.10% > kdeinit4: kdeinit4: kmix -session 102511e52251c60001304471 > 92001 root =A0 =A0 =A0 =A0 =A01 =A097 =A0 =A00 23452K 22256K CPU1 =A0 =A0= 1 =A0 0:00 =A00.00% [cc1] > 92017 root =A0 =A0 =A0 =A0 =A01 =A096 =A0 =A00 16172K 13440K RUN =A0 =A0 = 0 =A0 0:00 =A00.00% [cc1] > [snip] --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 10 13:51:34 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 C66351065672 for ; Fri, 10 Jun 2011 13:51:34 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 515DD8FC18 for ; Fri, 10 Jun 2011 13:51:33 +0000 (UTC) Received: from park.js.berklix.net (p5DCBE84C.dip.t-dialin.net [93.203.232.76]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p5ADpUrO098892; Fri, 10 Jun 2011 13:51:30 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p5ADp5D6022446; Fri, 10 Jun 2011 15:51:06 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p5ADoUA6073793; Fri, 10 Jun 2011 13:50:35 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201106101350.p5ADoUA6073793@fire.js.berklix.net> to: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 31 May 2011 18:34:04 +0200." <201105311634.p4VGY4SW004129@fire.js.berklix.net> Date: Fri, 10 Jun 2011 15:50:30 +0200 Sender: jhs@berklix.com Cc: Tom Evans , Alex Zbyslaw , Bruce Cran Subject: Re: /usr/share/calendar/calendar.british 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, 10 Jun 2011 13:51:34 -0000 "Julian H. Stacey" wrote: > Hi hackers@freebsd.org > Britain had a national holiday yesterday. FreeBSD didn't notice as no > /usr/share/calendar/calendar.british > Other countries have their dates listed, so I wrote src/ > http://www.freebsd.org/cgi/query-pr.cgi?pr=157466 > > If you'r British, or in Britain etc, please look at > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/calendars/calendar.british > & mail me additions/ corrections. Thanks for review/ corrections/ addiditions from 3 people cc'd. More welcome. I'd welcome hearing from a commiter who could commit it, after I merge any final input resulting from this posting. http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/calendars/calendar.british Now includes sub files to allow users to select subsets. http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/calendars/en_UK.ISO8859-1/ calendar.all calendar.events calendar.finance calendar.history calendar.holidays calendar.other calendar.religious Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; indent with "> "; Cumulative like a play script. Mail plain text: Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 10 14:38: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 1FCA3106566C for ; Fri, 10 Jun 2011 14:38:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D47208FC12 for ; Fri, 10 Jun 2011 14:38:30 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5AEZXt6043563 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2011 08:35:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1106102346110.1931@smasher> Date: Fri, 10 Jun 2011 08:35:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <334F868B-0CBF-490F-8090-4CD47082122F@bsdimp.com> References: <1106102346110.1931@smasher> To: Atom Smasher X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 10 Jun 2011 08:35:35 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org Subject: Re: freebsd under qemu - slow 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, 10 Jun 2011 14:38:31 -0000 On Jun 10, 2011, at 6:14 AM, Atom Smasher wrote: > new laptop: > LENOVO, 4313CTO, ThinkPad T510 > Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > Integrated Graphics Chipset: Intel(R) Arrandale > 4G RAM (DDR3-10600) >=20 > old laptop: > Acer, Navarro, Aspire 5100 > AMD Turion(tm) 64 Mobile Technology MK-36 1995.02-MHz > 2.5G RAM >=20 > apparently video on freebsd isn't yet working out with the Arrandale, = so i'm running ubuntu on the newer laptop and trying to get freebsd = running under qemu. it's working, but it's painfully slow. a few CPU = benchmarks show my old laptop running ten times faster!!! >=20 > CPU benchmarks between ubuntu on the new hardware and freebsd on the = old hardware, ubuntu is running about twice as fast. i'd hope to get = freebsd/qemu running at least as fast as the old hardware. >=20 > am i doing something wrong, or is this as good as it gets? Are you using the hardware virtualization acceleration features of qemu? = Are they enabled in your BIOS? I found they made a huge difference on = VirtualBox (which you might also try: it has worked for me better than = qemu) Warner= From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 00:46: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 A3EAB1065676 for ; Sat, 11 Jun 2011 00:46:35 +0000 (UTC) (envelope-from yanegomi@gmail.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 62CA88FC08 for ; Sat, 11 Jun 2011 00:46:35 +0000 (UTC) Received: by vws18 with SMTP id 18so3726776vws.13 for ; Fri, 10 Jun 2011 17:46:34 -0700 (PDT) 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=/F0PXIeFqs9w2G05usbk3aQOuK3d/42TZ1I74g9+2A8=; b=pqF1u2TmND/brnscL/EJ4+KJltNSwc1bQ4ifg+nGFuw5vAftpzAHx9XW0+2zM9vXar 0nXgV3JbFUCEug+D8Alrok6Gyq8ms+TV3ASYc6nmA/zr5XqDaGp2hiKML8dqMDwet7Am 3auR6+l8yWBr9UVuaXUkMofrhKtcbkUhD+/yA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FvVJ5B9aoIdYxqC/ysDUihZrJJzJj9CrfqzTSib7nhkztlLuWcivMlwojucpaxA6Id 2nwQR7chi6+GV4ee2wcT0atkws1MSmSU76LG0Mw5tWcdVTdY9i1RzjQkez1GnO9omymJ vVYkdT7Ui3XQObTcaeTORzURHiGTBrCrWQhMw= MIME-Version: 1.0 Received: by 10.220.187.76 with SMTP id cv12mr1059682vcb.128.1307753194450; Fri, 10 Jun 2011 17:46:34 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Fri, 10 Jun 2011 17:46:34 -0700 (PDT) Date: Fri, 10 Jun 2011 17:46:34 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: sysctl_handle_int questions 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, 11 Jun 2011 00:46:35 -0000 Looking at sysctl_handle_int in a 7.2-ish tree... 1. What is the purpose of arg2? In all cases in /sys minus a few, arg2 appears to be zeroed out: $ grep -Ir 'sysctl_handle_int.*[^0], req)' . 2>/dev/null ./amd64/amd64/pmap.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./amd64/amd64/pmap.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./dev/acpi_support/acpi_aiboost.c: error = sysctl_handle_int(oidp, &val, 0 , req); ./dev/acpi_support/acpi_aiboost.c: error = sysctl_handle_int(oidp, &val, 0 , req); ./dev/acpi_support/acpi_aiboost.c: error = sysctl_handle_int(oidp, &val, 0 , req); ./dev/cxgb/cxgb_sge.c: err = sysctl_handle_int(oidp, &coalesce_usecs, arg2, req); ./dev/mxge/if_mxge.c: err = sysctl_handle_int(oidp, &intr_coal_delay, arg2, req); ./dev/mxge/if_mxge.c: err = sysctl_handle_int(oidp, &enabled, arg2, req); ./dev/mxge/if_mxge.c: err = sysctl_handle_int(oidp, &lro_cnt, arg2, req); ./dev/mxge/if_mxge.c: err = sysctl_handle_int(oidp, arg1, arg2, req); ./dev/nxge/if_nxge.c: status = sysctl_handle_int(oidp, &request, arg2, req); ./dev/random/randomdev_soft.c: return sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./kern/subr_prf.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./netinet/in_pcb.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./netinet/sctp_sysctl.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); ./netinet/sctp_sysctl.c: error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2, req); 2. Is there a proper way to restore the value in a SYSCTL_PROC handler instead of saving a value to a local, passing in newp via a global value, and restoring if sysctl_handle_int returned a nonzero value, e.g. old_global = global; error = sysctl_handle_int(oidp, &global, old_global, req); if (!error && req->newptr) { /* * Do something fun with global.. maybe capture an error via `error' and * restore appropriately down below, but that's optional.. */ } if (error) global = old_global; I'm asking because I tried passing in a local variable instead of the global in the function, and that got printed out later on via sysctlbyname(3), and well... it didn't work out too well (sysctlbyname(3) was returning a random uninitialized value from the stack). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 00:48:56 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 ED132106567C for ; Sat, 11 Jun 2011 00:48:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F97E8FC08 for ; Sat, 11 Jun 2011 00:48:55 +0000 (UTC) Received: by vxc34 with SMTP id 34so3734649vxc.13 for ; Fri, 10 Jun 2011 17:48:54 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=DIOS8swN077c6n/yR0JJKHhnDgcgUoUJYuXpTGUfIUs=; b=OwYhBKK7gCsAWv2AvMfU0yFMhfZD6d0lb9LtDB8bAzOyqSnh1381eheleoUxqJkyT3 wgvYVgWcjBIzfJKcgivFwyKLnHSAdhcQGUe0oKgki2mD15cVSIr7hu+ugIBz+3CnEz0E 3EeYg/BBqBfUwemOWZ1UKmYaAzVYsQMaenr3o= 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 :content-type:content-transfer-encoding; b=UaaOMQ3MrsbFIGjCCq6LatbzowbwyxFTeo/9Hl2WkHyssI89lBwULqo7ojICrw0al/ vmE4NfXFzNuaqQyXr0liOP7Uk2+5UZ/D7rx6CVQbRE2SyButDYT9Ebq/L7yzeDsdQrIE gZ+Y0rz1dJumcHoXZn9++N7lgWPzQtYS/7/+Q= MIME-Version: 1.0 Received: by 10.220.213.195 with SMTP id gx3mr1073489vcb.23.1307753334662; Fri, 10 Jun 2011 17:48:54 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Fri, 10 Jun 2011 17:48:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jun 2011 17:48:54 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: sysctl_handle_int questions 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, 11 Jun 2011 00:48:56 -0000 On Fri, Jun 10, 2011 at 5:46 PM, Garrett Cooper wrote: > =A0 =A0Looking at sysctl_handle_int in a 7.2-ish tree... > > 1. What is the purpose of arg2? In all cases in /sys minus a few, arg2 > appears to be zeroed out: > > $ grep -Ir 'sysctl_handle_int.*[^0], req)' . 2>/dev/null > ./amd64/amd64/pmap.c: =A0 error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./amd64/amd64/pmap.c: =A0 error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./dev/acpi_support/acpi_aiboost.c: =A0 =A0 =A0error =3D > sysctl_handle_int(oidp, &val, 0 , req); > ./dev/acpi_support/acpi_aiboost.c: =A0 =A0 =A0error =3D > sysctl_handle_int(oidp, &val, 0 , req); > ./dev/acpi_support/acpi_aiboost.c: =A0 =A0 =A0error =3D > sysctl_handle_int(oidp, &val, 0 , req); > ./dev/cxgb/cxgb_sge.c: =A0 =A0 =A0 =A0err =3D sysctl_handle_int(oidp, > &coalesce_usecs, arg2, req); > ./dev/mxge/if_mxge.c: =A0 =A0 =A0 =A0err =3D sysctl_handle_int(oidp, > &intr_coal_delay, arg2, req); > ./dev/mxge/if_mxge.c: =A0 =A0 =A0 =A0err =3D sysctl_handle_int(oidp, &ena= bled, arg2, req); > ./dev/mxge/if_mxge.c: =A0 err =3D sysctl_handle_int(oidp, &lro_cnt, arg2,= req); > ./dev/mxge/if_mxge.c: =A0 =A0 =A0 =A0err =3D sysctl_handle_int(oidp, arg1= , arg2, req); > ./dev/nxge/if_nxge.c: =A0 status =3D sysctl_handle_int(oidp, &request, ar= g2, req); > ./dev/random/randomdev_soft.c: =A0return sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./kern/subr_prf.c: =A0 =A0 =A0error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./netinet/in_pcb.c: =A0 =A0 error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./netinet/sctp_sysctl.c: =A0 =A0 =A0 =A0error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > ./netinet/sctp_sysctl.c: =A0 =A0 =A0 =A0error =3D sysctl_handle_int(oidp, > oidp->oid_arg1, oidp->oid_arg2, req); > > 2. Is there a proper way to restore the value in a SYSCTL_PROC handler > instead of saving a value to a local, passing in newp via a global > value, and restoring if sysctl_handle_int returned a nonzero value, > e.g. > > old_global =3D global; > error =3D sysctl_handle_int(oidp, &global, old_global, req); > if (!error && req->newptr) { > =A0 =A0/* > =A0 =A0 * Do something fun with global.. maybe capture an error via `erro= r' and > =A0 =A0 * restore appropriately down below, but that's optional.. > =A0 =A0 */ > } > if (error) > =A0 =A0global =3D old_global; > > =A0 =A0I'm asking because I tried passing in a local variable instead of > the global in the function, and that got printed out later on via > sysctlbyname(3), and well... it didn't work out too well > (sysctlbyname(3) was returning a random uninitialized value from the > stack). Nevermind. I think I got it figured out now (my brain was just a bit scrambled after staring at the screen for a bit). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 14:16:36 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 3FC72106566B; Sat, 11 Jun 2011 14:16:36 +0000 (UTC) (envelope-from kmacybsd@gmail.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 BBEEA8FC0C; Sat, 11 Jun 2011 14:16:35 +0000 (UTC) Received: by vws18 with SMTP id 18so4037151vws.13 for ; Sat, 11 Jun 2011 07:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bB2CaWSNAlRPcxAKz9gyiGhtOACl2tO+LTtcA2ZOCAE=; b=oan3JYImdKyjrx1Jo38VVfXVgWx/XkCJfXXJInAUEgz69bfWt5ucyN6S8vf5sMLlt1 CYOSe4+euKp2ND7kpHcdZDyz8UDJb8DUcSaN6kWQfW7iUT0vnWhlH8TBgfmizX5zuCzi 8+cJ2YV3VHHDy4Niw9/GxL4D76wskZxSAELSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nzyYj+7nf9PWcTsCntqRW2bQ5TN6EWq+X0MfjhKrMGtA0vWe/2+OPD2PxYB7Xwn6Eq 0YqzX7zvBtoBL5AvRNSIvT2vHySLLrdO7XM5vOaIchyeuXODkRiuPKhGFubZxdVoLBRH Q5v14vy8hfIRjeFA8wrbllM7ZL1O47OC21I6Y= MIME-Version: 1.0 Received: by 10.52.175.133 with SMTP id ca5mr2848256vdc.82.1307801794681; Sat, 11 Jun 2011 07:16:34 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.74 with HTTP; Sat, 11 Jun 2011 07:16:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Jun 2011 16:16:34 +0200 X-Google-Sender-Auth: u4sdlcFDGWo5MmDrbVyztTQEw2c Message-ID: From: "K. Macy" To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , grarpamp , "freebsd-net@freebsd.org" Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 11 Jun 2011 14:16:36 -0000 Oops, second 10 GigE should obviously be 1GigE On Tuesday, June 7, 2011, K. Macy wrote: > All 10GigE NICs and some newer 10 GigE NICs have multiple hardware > queues with a separate MSI-x vector per queue, where each vector is > directed to a different CPU. The current operating model is to have a > separate interrupt thread per vector. This obviously gets bogged down > if one has multiple cards as the interrupt threads end up requiring > the scheduler to distribute work fairly between cards as multiple > threads will end up running on the same CPUs. Nokia had a reasonable > interface for coping with this that was reminiscent of NAPI whereby > cooperative sharing between interfaces was provided by having a single > taskqueue thread per-core and the cards would queue tasks (which would > be re-queued if more than a certain amount of work were required) as > interrupts were delivered. There has been talk off and on of porting > this "net_task" interface to freebsd. > > None of this addresses PF_RING's facility for pushing packets in to > userland - but presumably Rizzo's netmap work addresses those in need > of that sufficiently. > > Cheers, > Kip > > On Tue, Jun 7, 2011 at 4:13 AM, grarpamp wrote: >> Is this work part of what's needed to enable the FreeBSD >> equivalent of TNAPI? >> >> I know we've got polling. And probably MSI-X in a couple drivers. >> Pretty sure there is still one CPU doing the interrupt work? >> And none of the multiple queue thread spreading tech exists? >> >> http://www.ntop.org/blog >> http://www.ntop.org/TNAPI.html >> TNAPI attempts to solve the following problems: >> =A0 =A0* Distribute the traffic across cores (i.e. the more core the mor= e >> scalable is your networking application) for improving scalability. >> =A0 =A0* Poll packets simultaneously from each RX queue (contraty to >> sequential NAPI polling) for fetching packets as fast as possible >> hence improve performance. >> =A0 =A0* Through PF_RING, expose the RX queues to the userland so that >> the application can spawn one thread per queue hence avoid using >> semaphores at all. >> TNAPI achieves all this by starting one thread per RX queue. Received >> packets are then pushed to PF_RING (if available) or through the >> standard Linux stack. However in order to fully exploit this >> technology it is necessary to use PF_RING as it provides a straight >> packet path from kernel to userland. Furthermore it allows to create a >> virtual ethernet card per RX queue. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 15:49: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 9421E1065670; Sat, 11 Jun 2011 15:49:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 719338FC0A; Sat, 11 Jun 2011 15:49:18 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A594246B46; Sat, 11 Jun 2011 11:49:17 -0400 (EDT) Date: Sat, 11 Jun 2011 16:49:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: grarpamp In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 11 Jun 2011 15:49:18 -0000 On Mon, 6 Jun 2011, grarpamp wrote: > I know we've got polling. And probably MSI-X in a couple drivers. Pretty > sure there is still one CPU doing the interrupt work? And none of the > multiple queue thread spreading tech exists? Actually, with most recent 10gbps cards, and even 1gbps cards, we process inbound data with as many CPUs as the hardware has MSI-X enabled input and output queues. So "a couple" understates things significantly. > * Through PF_RING, expose the RX queues to the userland so that > the application can spawn one thread per queue hence avoid using > semaphores at all. I'm probably a bit out of date, but last I checked, PF_RING still implied copying, albeit into shared memory buffers. We support shared memory between the kernel and userspace for BPF and have done for quite a while. However, right now a single shared memory buffer is shared for all receive queues on a NIC. We have a Google summer of code student working on this actively right now -- my hope is that by the end of the summer we'll have a pretty functional system that allows different shared memory buffers to be used for different input queues. In particular, applications will be able to query the set of queues available, detect CPU affinity for them, and bind particular shared memory rings to particular queues. It's worth observing that for many types of high-performance analysis, BPF's packet filtering and truncation support is quite helpful, and if you're going to use multiple hardware threads per input queue anyway, you actually get a nice split this way (as long as those threads share L2 caches). Luigi's work on mapping receive rings straight into userspace looks quite interesting, but I'm pretty behind currently, so haven't had a chance to read his NetMap paper. The direct mapping of rings approach is what a number of high-performance FreeBSD shops have been doing for a while, but none had generalised it sufficiently to merge into our base stack. I hope to see this happen in the next year. Robert From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 16:40:15 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 831351065674 for ; Sat, 11 Jun 2011 16:40:15 +0000 (UTC) (envelope-from yanegomi@gmail.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 1D4028FC0A for ; Sat, 11 Jun 2011 16:40:14 +0000 (UTC) Received: by vws18 with SMTP id 18so4103349vws.13 for ; Sat, 11 Jun 2011 09:40:14 -0700 (PDT) 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:cc :content-type; bh=WStpY8F6Q2IwYbiBo2aQvFxHegu/0UO3dnleG4syUoc=; b=D3XnHPzSkTh62oYrq/NPGy7BoUw64zdyMWy6/RALJh+N01cv0mF0XCMK0pJmPyyk+6 W0Nu7cAj8k/0jXKNUpHXcdFhdHOCb3k0ElXe5VnHu0ttmkOEfku99jCMYvCV/5lEul74 3W4qmx4s+HdTV32ajiQHraF627Cm1r6Gek0qU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=rwcQlWfRxGmlESlrpOXeJgHYYwd6FGTxlS9sIzKjBF7hHkp+W64gyFczi09ijnfhoV wOEsqj6LtT2KsUCZPzryJgJ33jo/sniwS2NcV8y5iNg8RDs7YgeZ91ttXU4frUanteBP SXNeTqXZmuYFHLwcZdlvZwWEf1tXfhXdNw/TY= MIME-Version: 1.0 Received: by 10.52.98.231 with SMTP id el7mr4762011vdb.229.1307810413997; Sat, 11 Jun 2011 09:40:13 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Sat, 11 Jun 2011 09:40:13 -0700 (PDT) Date: Sat, 11 Jun 2011 09:40:13 -0700 Message-ID: From: Garrett Cooper To: sam@FreeBSD.org Content-Type: multipart/mixed; boundary=20cf307ca26428ef7504a5725723 Cc: freebsd-hackers@freebsd.org Subject: [PATCH] do bswap32 properly with safe(4) 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, 11 Jun 2011 16:40:15 -0000 --20cf307ca26428ef7504a5725723 Content-Type: text/plain; charset=ISO-8859-1 Hi Sam! For some odd reason every time I compile GENERIC (i.e. don't try to compile safe(4) as a standalone module, and I don't compile it with my standard test kernel) I run into an error where the compiler complains about the result from bswap32 in safe(4) being unused. This patch fixes that warning so the module compiles properly and more importantly does the network to host conversions which may be required for the driver under some architectures. Thanks! -Garrett --20cf307ca26428ef7504a5725723 Content-Type: text/x-patch; charset=US-ASCII; name="sys-safe-do-bswap32.patch" Content-Disposition: attachment; filename="sys-safe-do-bswap32.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gossid5q0 SW5kZXg6IHN5cy9kZXYvc2FmZS9zYWZlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9zYWZlL3Nh ZmUuYwkocmV2aXNpb24gMjIyOTgwKQorKysgc3lzL2Rldi9zYWZlL3NhZmUuYwkod29ya2luZyBj b3B5KQpAQCAtMTU4MCw5ICsxNTgwLDEyIEBACiAJCQkJICogU0hBLTEgSUNWJ3MgYXJlIGJ5dGUt c3dhcHBlZDsgZml4ICdlbSB1cAogCQkJCSAqIGJlZm9yZSBjb3B5IHRoZW0gdG8gdGhlaXIgZGVz dGluYXRpb24uCiAJCQkJICovCi0JCQkJYnN3YXAzMihyZS0+cmVfc2FzdGF0ZS5zYV9zYXZlZF9p bmRpZ2VzdFswXSk7Ci0JCQkJYnN3YXAzMihyZS0+cmVfc2FzdGF0ZS5zYV9zYXZlZF9pbmRpZ2Vz dFsxXSk7Ci0JCQkJYnN3YXAzMihyZS0+cmVfc2FzdGF0ZS5zYV9zYXZlZF9pbmRpZ2VzdFsyXSk7 CisJCQkJcmUtPnJlX3Nhc3RhdGUuc2Ffc2F2ZWRfaW5kaWdlc3RbMF0gPQorCQkJCSAgICBic3dh cDMyKHJlLT5yZV9zYXN0YXRlLnNhX3NhdmVkX2luZGlnZXN0WzBdKTsKKwkJCQlyZS0+cmVfc2Fz dGF0ZS5zYV9zYXZlZF9pbmRpZ2VzdFsxXSA9CisJCQkJICAgIGJzd2FwMzIocmUtPnJlX3Nhc3Rh dGUuc2Ffc2F2ZWRfaW5kaWdlc3RbMV0pOworCQkJCXJlLT5yZV9zYXN0YXRlLnNhX3NhdmVkX2lu ZGlnZXN0WzJdID0KKwkJCQkgICAgYnN3YXAzMihyZS0+cmVfc2FzdGF0ZS5zYV9zYXZlZF9pbmRp Z2VzdFsyXSk7CiAJCQl9CiAJCQljcnlwdG9fY29weWJhY2soY3JwLT5jcnBfZmxhZ3MsIGNycC0+ Y3JwX2J1ZiwKIAkJCSAgICBjcmQtPmNyZF9pbmplY3QsCg== --20cf307ca26428ef7504a5725723-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 11 17:57:39 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 9DA61106566B; Sat, 11 Jun 2011 17:57:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 639E68FC0A; Sat, 11 Jun 2011 17:57:39 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 080FD7300A; Sat, 11 Jun 2011 20:13:53 +0200 (CEST) Date: Sat, 11 Jun 2011 20:13:53 +0200 From: Luigi Rizzo To: Robert Watson Message-ID: <20110611181352.GA67777@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, grarpamp , freebsd-net@freebsd.org Subject: Re: FreeBSD I/OAT (QuickData now?) driver 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, 11 Jun 2011 17:57:39 -0000 On Sat, Jun 11, 2011 at 04:49:17PM +0100, Robert Watson wrote: > > On Mon, 6 Jun 2011, grarpamp wrote: > > >I know we've got polling. And probably MSI-X in a couple drivers. Pretty > >sure there is still one CPU doing the interrupt work? And none of the > >multiple queue thread spreading tech exists? > > Actually, with most recent 10gbps cards, and even 1gbps cards, we process > inbound data with as many CPUs as the hardware has MSI-X enabled input and > output queues. So "a couple" understates things significantly. > > > * Through PF_RING, expose the RX queues to the userland so that > >the application can spawn one thread per queue hence avoid using > >semaphores at all. > > I'm probably a bit out of date, but last I checked, PF_RING still implied > copying, albeit into shared memory buffers. We support shared memory > between the kernel and userspace for BPF and have done for quite a while. > However, right now a single shared memory buffer is shared for all receive > queues on a NIC. We have a Google summer of code student working on this > actively right now -- my hope is that by the end of the summer we'll have a > pretty functional system that allows different shared memory buffers to be > used for different input queues. In particular, applications will be able > to query the set of queues available, detect CPU affinity for them, and > bind particular shared memory rings to particular queues. It's worth > observing that for many types of high-performance analysis, BPF's packet > filtering and truncation support is quite helpful, and if you're going to > use multiple hardware threads per input queue anyway, you actually get a > nice split this way (as long as those threads share L2 caches). > > Luigi's work on mapping receive rings straight into userspace looks quite > interesting, but I'm pretty behind currently, so haven't had a chance to > read his NetMap paper. The direct mapping of rings approach is what a > number of high-performance FreeBSD shops have been doing for a while, but > none had generalised it sufficiently to merge into our base stack. I hope > to see this happen in the next year. for the records, netmap also maps transmit rings, makes them device independent, and supports the mapping of rings to different cores through standard setaffinity() calls. I'd really encourage people to look at the code (e.g. the pkt-gen.c program, which is part of the archive) so you can see how easy it is to use. And of course, any feedback and suggestions are welcome http://info.iet.unipi.it/~luigi/netmap/ cheers luigi