From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 09:39:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83525106564A for ; Sun, 15 Jul 2012 09:39:14 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 247228FC17 for ; Sun, 15 Jul 2012 09:39:13 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3314861qcs.13 for ; Sun, 15 Jul 2012 02:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:face:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=aoDUN8+HdUWIqEWfr34E96/Bz+7j3IzXKOfi5sx+PCk=; b=WqB83+WBUEfaGl0qBcLOrUE2bWQ5fRb2JUYS79awc3U7tyGlti43mtzFckPC0Ms9gC h0yCa64teJP2NlD1KA7y+9Lh8216be1QOyFXcALYDaXnRI/wjhcbMUNFsCBKrFdbJ82K rgMXWRVg70zQoYrgLdfHnFBqOYPQPmZJ7BqhJEdfYKgVPoSy4JSETQbU/q6Q5eEEiyF1 V6Di9KconbvAnDVEaPczKSn4nWGNhy3M/gGQDyD6A5n838mFjeCwMbgQPp0TByR80n5G 3clWNohhINmMaaOzqr6Jx8yNg4klL6hr9HOhTWTgHwT2efjjEp547o2/S/ztI6mSeWMV 2hRw== Received: by 10.224.192.133 with SMTP id dq5mr14117822qab.51.1342345153358; Sun, 15 Jul 2012 02:39:13 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id i5sm10670142qak.11.2012.07.15.02.39.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2012 02:39:13 -0700 (PDT) Date: Sun, 15 Jul 2012 05:39:03 -0400 From: Mike Meyer To: Doug Barton Message-ID: <20120715053903.089b27b2@bhuda.mired.org> In-Reply-To: <5001D6C7.4070103@FreeBSD.org> References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> <5001D6C7.4070103@FreeBSD.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlBFTueZ7iA7PKPx7/yq6Cmho9Q3TP+C1KKTmpCvS/DCmPK9MO5prYNaEpNpQcTWwyNxUZl Cc: Adam Vande More , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.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: Sun, 15 Jul 2012 09:39:14 -0000 On Sat, 14 Jul 2012 13:29:59 -0700 Doug Barton wrote: > For the OP, make sure you have the latest BIOS. I had a similar problem > with vt-x and it was solved by a later BIOS upgrade. And *that* solved the problem. The performance is much better, now being a lot like using a poor wireless mouse. My thanks to everyone who took time to help me. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 09:42:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A9DA91065677 for ; Sun, 15 Jul 2012 09:42:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B97CB164138; Sun, 15 Jul 2012 09:42:55 +0000 (UTC) Message-ID: <5002909F.7080903@FreeBSD.org> Date: Sun, 15 Jul 2012 02:42:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Meyer References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> <5001D6C7.4070103@FreeBSD.org> <20120715053903.089b27b2@bhuda.mired.org> In-Reply-To: <20120715053903.089b27b2@bhuda.mired.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.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: Sun, 15 Jul 2012 09:42:58 -0000 On 07/15/2012 02:39, Mike Meyer wrote: > On Sat, 14 Jul 2012 13:29:59 -0700 > Doug Barton wrote: > >> For the OP, make sure you have the latest BIOS. I had a similar problem >> with vt-x and it was solved by a later BIOS upgrade. > > And *that* solved the problem. The performance is much better, now > being a lot like using a poor wireless mouse. > > My thanks to everyone who took time to help me. I'm glad to help, and more glad that it was that simple of a solution. :) Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 10:46:11 2012 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 37CD4106564A; Sun, 15 Jul 2012 10:46:11 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 96DC88FC08; Sun, 15 Jul 2012 10:46:10 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6FAk4s1001781; Sun, 15 Jul 2012 12:46:05 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6FAk4YN001778; Sun, 15 Jul 2012 12:46:04 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 15 Jul 2012 12:46:04 +0200 (CEST) From: Wojciech Puchar To: Mike Meyer In-Reply-To: <20120715053903.089b27b2@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> <5001D6C7.4070103@FreeBSD.org> <20120715053903.089b27b2@bhuda.mired.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 15 Jul 2012 12:46:05 +0200 (CEST) Cc: Adam Vande More , Doug Barton , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.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: Sun, 15 Jul 2012 10:46:11 -0000 > being a lot like using a poor wireless mouse. > > My thanks to everyone who took time to help me. > by the way anyone know WHY BIOS is over control of that CPU feature? It is quite scary to know that my FreeBSD system isn't really under FreeBSD control. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 13:39:13 2012 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 60316106564A for ; Sun, 15 Jul 2012 13:39:13 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 39CA88FC17 for ; Sun, 15 Jul 2012 13:39:12 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SqP2Q-0008IL-Jv for freebsd-hackers@freebsd.org; Sun, 15 Jul 2012 06:39:06 -0700 Date: Sun, 15 Jul 2012 06:39:06 -0700 (PDT) From: Jakub Lach To: freebsd-hackers@freebsd.org Message-ID: <1342359546590-5727055.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Clang '-g' unused warnings in FreeBSD (linking) 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, 15 Jul 2012 13:39:13 -0000 Hello. While this is old "bug" upstream: http://llvm.org/bugs/show_bug.cgi?id=8611 http://llvm.org/bugs/show_bug.cgi?id=8630 Here, (FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: x86_64-unknown-freebsd9.0) Passing -g during linking (which lot's of projects do by including CFLAGS in linking) I still get "clang: warning: argument unused during compilation: '-g'" -- View this message in context: http://freebsd.1045724.n5.nabble.com/Clang-g-unused-warnings-in-FreeBSD-linking-tp5727055.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 14:04:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2886106566B for ; Sun, 15 Jul 2012 14:04:38 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF588FC0A for ; Sun, 15 Jul 2012 14:04:38 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SqPR8-0003Om-61 for freebsd-hackers@freebsd.org; Sun, 15 Jul 2012 07:04:38 -0700 Date: Sun, 15 Jul 2012 07:04:38 -0700 (PDT) From: Jakub Lach To: freebsd-hackers@freebsd.org Message-ID: <1342361078180-5727066.post@n5.nabble.com> In-Reply-To: <1342359546590-5727055.post@n5.nabble.com> References: <1342359546590-5727055.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Clang '-g' unused warnings in FreeBSD (linking) 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, 15 Jul 2012 14:04:38 -0000 Maybe I should include a question too, so I have better chance of getting answer :) Is this intended behaviour? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Clang-g-unused-warnings-in-FreeBSD-linking-tp5727055p5727066.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 17:32:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A2F31065670 for ; Sun, 15 Jul 2012 17:32:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id B64D88FC0C for ; Sun, 15 Jul 2012 17:32:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e862:47d8:b5d0:2580] (unknown [IPv6:2001:7b8:3a7:0:e862:47d8:b5d0:2580]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E0CFF5C37; Sun, 15 Jul 2012 19:32:37 +0200 (CEST) Message-ID: <5002FEB3.3040708@FreeBSD.org> Date: Sun, 15 Jul 2012 19:32:35 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Jakub Lach References: <1342359546590-5727055.post@n5.nabble.com> In-Reply-To: <1342359546590-5727055.post@n5.nabble.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Clang '-g' unused warnings in FreeBSD (linking) 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, 15 Jul 2012 17:32:39 -0000 On 2012-07-15 15:39, Jakub Lach wrote: > While this is old "bug" upstream: > > http://llvm.org/bugs/show_bug.cgi?id=8611 > > http://llvm.org/bugs/show_bug.cgi?id=8630 > > Here, > > (FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 > Target: x86_64-unknown-freebsd9.0) > > Passing -g during linking (which lot's of projects do by > including CFLAGS in linking) I still get > > "clang: warning: argument unused during compilation: '-g'" ... On 2012-07-15 16:04, Jakub Lach wrote: > Maybe I should include a question too, so I have better chance > of getting answer :) > > Is this intended behaviour? This is a bit typical issue for clang, which originates in the way it parses command line arguments: different parts of the compiler stages 'claim' arguments, and any that are left at the end are reported as unused. Regarding the LLVM PRs you mentioned, one could argue that passing '-g' to the link stage is nonsensical, since ld cannot add debug information, it can only remove it (via the '-s' flag). But since it is apparently common to do this, it may be a bit too annoying to complain about it. In any case, upstream fixed it for Linux, but not for any other operating system. I will make a similar fix for FreeBSD, and send it upstream too. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 18:08:44 2012 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 548EA1065672; Sun, 15 Jul 2012 18:08:44 +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 C56A18FC08; Sun, 15 Jul 2012 18:08:43 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6FI8pbq090301; Sun, 15 Jul 2012 21:08:51 +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.5/8.14.5) with ESMTP id q6FI8djo065629; Sun, 15 Jul 2012 21:08:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6FI8dZ4065628; Sun, 15 Jul 2012 21:08:39 +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: Sun, 15 Jul 2012 21:08:39 +0300 From: Konstantin Belousov To: Dimitry Andric Message-ID: <20120715180839.GK2338@deviant.kiev.zoral.com.ua> References: <1342359546590-5727055.post@n5.nabble.com> <5002FEB3.3040708@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rbnuKbTS42rgQRRy" Content-Disposition: inline In-Reply-To: <5002FEB3.3040708@FreeBSD.org> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Jakub Lach Subject: Re: Clang '-g' unused warnings in FreeBSD (linking) 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, 15 Jul 2012 18:08:44 -0000 --rbnuKbTS42rgQRRy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 15, 2012 at 07:32:35PM +0200, Dimitry Andric wrote: > On 2012-07-15 15:39, Jakub Lach wrote: > > While this is old "bug" upstream: > >=20 > > http://llvm.org/bugs/show_bug.cgi?id=3D8611 > >=20 > > http://llvm.org/bugs/show_bug.cgi?id=3D8630 > >=20 > > Here,=20 > >=20 > > (FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 > > Target: x86_64-unknown-freebsd9.0) > >=20 > > Passing -g during linking (which lot's of projects do by=20 > > including CFLAGS in linking) I still get=20 > >=20 > > "clang: warning: argument unused during compilation: '-g'" > ... > On 2012-07-15 16:04, Jakub Lach wrote: > > Maybe I should include a question too, so I have better chance=20 > > of getting answer :) > >=20 > > Is this intended behaviour?=20 >=20 > This is a bit typical issue for clang, which originates in the way it > parses command line arguments: different parts of the compiler stages > 'claim' arguments, and any that are left at the end are reported as > unused. >=20 > Regarding the LLVM PRs you mentioned, one could argue that passing '-g' > to the link stage is nonsensical, since ld cannot add debug information, > it can only remove it (via the '-s' flag). But since it is apparently > common to do this, it may be a bit too annoying to complain about it. >=20 > In any case, upstream fixed it for Linux, but not for any other > operating system. I will make a similar fix for FreeBSD, and send it > upstream too. Note that historical ld(1) did emited debugging information into resulting binary only if -g was specified, so the linker flag is not always 'meaningless'. I suspect that Solaris ld still behaves this way. --rbnuKbTS42rgQRRy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlADBycACgkQC3+MBN1Mb4hDWwCeOcKhBfpscY1ItVS13naZJh8T M/0AoOFkuXRg3zb7HrF+oXyrCzJ/md8/ =b+HK -----END PGP SIGNATURE----- --rbnuKbTS42rgQRRy-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 19:04:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 739FE1065760 for ; Sun, 15 Jul 2012 19:04:36 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3C48FC12 for ; Sun, 15 Jul 2012 19:04:36 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SqU7P-0002Ah-8t for freebsd-hackers@freebsd.org; Sun, 15 Jul 2012 12:04:35 -0700 Date: Sun, 15 Jul 2012 12:04:35 -0700 (PDT) From: Jakub Lach To: freebsd-hackers@freebsd.org Message-ID: <1342379075269-5727113.post@n5.nabble.com> In-Reply-To: <20120715180839.GK2338@deviant.kiev.zoral.com.ua> References: <1342359546590-5727055.post@n5.nabble.com> <5002FEB3.3040708@FreeBSD.org> <20120715180839.GK2338@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Clang '-g' unused warnings in FreeBSD (linking) 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, 15 Jul 2012 19:04:36 -0000 Thanks, both replies were very informative! Regarding > one could argue that passing '-g' to the link stage is nonsensical, > since ld cannot add debug information, it can only remove it (via the '-s' > flag). Is precisely why I was asking If this was conscious decision on FreeBSD part. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Clang-g-unused-warnings-in-FreeBSD-linking-tp5727055p5727113.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 10:23:43 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC0601065679; Mon, 16 Jul 2012 10:23: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 7BEF58FC1C; Mon, 16 Jul 2012 10:23:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA02136; Mon, 16 Jul 2012 13:23:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5003EBAB.6030507@FreeBSD.org> Date: Mon, 16 Jul 2012 13:23:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 10:23:44 -0000 on 26/06/2012 15:50 Andrey V. Elsukov said the following: > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c First of all, it's hard to parse the above sentence. "probing ... should be greatly increased". Probing what? :-) If probing time, then we don't want that ;-) I looked through the ZFS-related part and here are a few comments: 1. I think that the predominant indentation style of i386/loader/main.c should be preserved for consistency. 2. I am not sure if I like the approach of moving partition tasting code into common ZFS code (zfs.c). On one hand, it now makes sense because the new partition iteration code is machine-independent. On the other hand, the reason that I added arch_zfs_probe method was to give platforms full control over which partitions and in what order are probed. It seems to be important for some of them. So, I like how your new partition interface makes it much easier to ZFS-probe partitions, but I would prefer to have that code in arch_zfs_probe implementations rather than in zfs_probe_dev. 3. Related to the above. In what shape is sparc64 ZFS support in your branch? Have you tried to adapt it to the new model too? It's the platform that has special requirements for disk/partition probing order. Marius can help with additional information and testing here. Overall, thank you very much for this work! I believe that it moves us in the correct direction. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 10:57:41 2012 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 241DD106564A; Mon, 16 Jul 2012 10:57:41 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 86D168FC0A; Mon, 16 Jul 2012 10:57:40 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 36DB0B8027; Mon, 16 Jul 2012 14:57:39 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 18A56B8026; Mon, 16 Jul 2012 14:57:39 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 13B88BA07F; Mon, 16 Jul 2012 14:57:39 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id CFFE4BA07A; Mon, 16 Jul 2012 14:57:38 +0400 (MSK) Message-ID: <5003F39D.6030808@FreeBSD.org> Date: Mon, 16 Jul 2012 14:57:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Andriy Gapon References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> In-Reply-To: <5003EBAB.6030507@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2E5F3064C6DDEFA89A2B846" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 10:57:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2E5F3064C6DDEFA89A2B846 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.07.2012 14:23, Andriy Gapon wrote: > on 26/06/2012 15:50 Andrey V. Elsukov said the following: >> 3. ZFS code now uses new API and probing on the systems with many disk= s >> should be greatly increased: >> zfs/zfs.c >> i386/loader/main.c >=20 > First of all, it's hard to parse the above sentence. "probing ... shoul= d be > greatly increased". Probing what? :-) If probing time, then we don't = want that ;-) >=20 > I looked through the ZFS-related part and here are a few comments: Thanks for that. > 1. I think that the predominant indentation style of i386/loader/main.c= should be > preserved for consistency. >=20 > 2. I am not sure if I like the approach of moving partition tasting cod= e into > common ZFS code (zfs.c). On one hand, it now makes sense because the n= ew > partition iteration code is machine-independent. On the other hand, th= e reason > that I added arch_zfs_probe method was to give platforms full control o= ver which > partitions and in what order are probed. It seems to be important for = some of them. > So, I like how your new partition interface makes it much easier to ZFS= -probe > partitions, but I would prefer to have that code in arch_zfs_probe impl= ementations > rather than in zfs_probe_dev. =46rom the other point of view, ZFS is not a just file system and it work= s directly with disks and partitions. And it seems to me this code will be = common for other architectures. > 3. Related to the above. In what shape is sparc64 ZFS support in your= branch? > Have you tried to adapt it to the new model too? > It's the platform that has special requirements for disk/partition prob= ing order. > Marius can help with additional information and testing here. Currently i have not received any feedback reports from the users who can= test patches on the other architectures. I added VTOC8 support to the part.c, = but it seems it is not needed and ofw can work without this. --=20 WBR, Andrey V. Elsukov --------------enigF2E5F3064C6DDEFA89A2B846 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJQA/OiAAoJEAHF6gQQyKF6REAH/A2waKFDxiljXNm+liofAd9Q GaIpYj+jNAIKMHHMLIdY2vM5HTQ61wIMHD7d83/uUekhBCAb/tqhhGelZn224O9j bHGPhW+YY36RVf2qs7QzX+ldSuHWq3B8MXzh5zzy71Znd4XzPfPudRqIynHLE5Jj 04OQNWjIgvTQqOJxIZwIT03vnKICRo2DWPWtxY0njMklBVoNfDMhyLwW2UBGjXfF sx4qks45aL+hc+uuZTJoRf/RwWRDk2srs9LtYAWr6B2Mez6JbyaOR5FwUmYNmDK1 7/AAF621+QFxZHlcUsrPW2hxugIBB49/6IkHEfxP19Oap8cj5edUucP1zxqI4B4= =80zQ -----END PGP SIGNATURE----- --------------enigF2E5F3064C6DDEFA89A2B846-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 11:05:48 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B97C106566B; Mon, 16 Jul 2012 11:05:48 +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 0C7FD8FC0C; Mon, 16 Jul 2012 11:05:46 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02660; Mon, 16 Jul 2012 14:05:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5003F589.40603@FreeBSD.org> Date: Mon, 16 Jul 2012 14:05:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> <5003F39D.6030808@FreeBSD.org> In-Reply-To: <5003F39D.6030808@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 11:05:48 -0000 on 16/07/2012 13:57 Andrey V. Elsukov said the following: > On 16.07.2012 14:23, Andriy Gapon wrote: >> on 26/06/2012 15:50 Andrey V. Elsukov said the following: >>> 3. ZFS code now uses new API and probing on the systems with many disks >>> should be greatly increased: >>> zfs/zfs.c >>> i386/loader/main.c >> >> First of all, it's hard to parse the above sentence. "probing ... should be >> greatly increased". Probing what? :-) If probing time, then we don't want that ;-) >> >> I looked through the ZFS-related part and here are a few comments: > > Thanks for that. > >> 1. I think that the predominant indentation style of i386/loader/main.c should be >> preserved for consistency. >> >> 2. I am not sure if I like the approach of moving partition tasting code into >> common ZFS code (zfs.c). On one hand, it now makes sense because the new >> partition iteration code is machine-independent. On the other hand, the reason >> that I added arch_zfs_probe method was to give platforms full control over which >> partitions and in what order are probed. It seems to be important for some of them. >> So, I like how your new partition interface makes it much easier to ZFS-probe >> partitions, but I would prefer to have that code in arch_zfs_probe implementations >> rather than in zfs_probe_dev. > > From the other point of view, ZFS is not a just file system and it works > directly with disks and partitions. And it seems to me this code will be common > for other architectures. Well, it seems that you haven't yet touched sparc64_zfs_probe. If you'll find that you don't have to use any ugly hacks there, then good. But my impression is that it would be easier to stick to the previous approach. >> 3. Related to the above. In what shape is sparc64 ZFS support in your branch? >> Have you tried to adapt it to the new model too? >> It's the platform that has special requirements for disk/partition probing order. >> Marius can help with additional information and testing here. > > Currently i have not received any feedback reports from the users who can test > patches on the other architectures. I added VTOC8 support to the part.c, but it > seems it is not needed and ofw can work without this. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 11:14:44 2012 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 964081065672; Mon, 16 Jul 2012 11:14:44 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 392208FC12; Mon, 16 Jul 2012 11:14:44 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 1B247B8027; Mon, 16 Jul 2012 15:14:43 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 1444DB8024; Mon, 16 Jul 2012 15:14:43 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 0FEDEBA081; Mon, 16 Jul 2012 15:14:43 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id C9FA9BA07B; Mon, 16 Jul 2012 15:14:42 +0400 (MSK) Message-ID: <5003F79E.1060706@FreeBSD.org> Date: Mon, 16 Jul 2012 15:14:38 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Andriy Gapon References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> <5003F39D.6030808@FreeBSD.org> <5003F589.40603@FreeBSD.org> In-Reply-To: <5003F589.40603@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F36F9C93BB298F6D6BA3735" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 11:14:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F36F9C93BB298F6D6BA3735 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.07.2012 15:05, Andriy Gapon wrote: >>> 2. I am not sure if I like the approach of moving partition tasting c= ode into >>> common ZFS code (zfs.c). On one hand, it now makes sense because the= new >>> partition iteration code is machine-independent. On the other hand, = the reason >>> that I added arch_zfs_probe method was to give platforms full control= over which >>> partitions and in what order are probed. It seems to be important fo= r some of them. >>> So, I like how your new partition interface makes it much easier to Z= FS-probe >>> partitions, but I would prefer to have that code in arch_zfs_probe im= plementations >>> rather than in zfs_probe_dev. >> >> From the other point of view, ZFS is not a just file system and it wor= ks >> directly with disks and partitions. And it seems to me this code will = be common >> for other architectures. >=20 > Well, it seems that you haven't yet touched sparc64_zfs_probe. Yes. It should work as before. But if Marius can suggest how to change ofw_disk.c to get disk size and s= ector size, then i will be able to break something here :) > If you'll find that you don't have to use any ugly hacks there, then go= od. > But my impression is that it would be easier to stick to the previous a= pproach. --=20 WBR, Andrey V. Elsukov --------------enig5F36F9C93BB298F6D6BA3735 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJQA/eiAAoJEAHF6gQQyKF6pCkH/3x3pOypbVF48Rfed0jZ/uRI LDUiwWg9ka9NrmX5DjiiNSYKNwQuZsk1EX6Gbv3HwHPHicpeOtes5HI8tlbXx2wo 9/FDJWQuKYo7Xz1AgvD3D026+xbmCXirw0mtYk7j3n9o5j8kuoqgtcsgmEFxjsR+ c8+074sLW1SGHaEjwjGgh9X4wSBpKbmlSEA7sCdc1Q0wX1P38IAjHUymKO7PDjCa XGcGt6KXbmfPWHNVy82Tru12lq0q7fAAxNpTa7nlTmqFmMldhwiw+EbRDOX9OAA6 uNvJ0p4BSUl7uJyjpdjApZeNqXGqqFrJVZsBk0vZEMrglM7knTA5Oy9ZdyecNN4= =Oj40 -----END PGP SIGNATURE----- --------------enig5F36F9C93BB298F6D6BA3735-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 11:31:44 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67755106567B; Mon, 16 Jul 2012 11:31:44 +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 EA6F78FC0A; Mon, 16 Jul 2012 11:31:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02997; Mon, 16 Jul 2012 14:31:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5003FB9D.90909@FreeBSD.org> Date: Mon, 16 Jul 2012 14:31:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> <5003F39D.6030808@FreeBSD.org> <5003F589.40603@FreeBSD.org> <5003F79E.1060706@FreeBSD.org> In-Reply-To: <5003F79E.1060706@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 11:31:44 -0000 on 16/07/2012 14:14 Andrey V. Elsukov said the following: > On 16.07.2012 15:05, Andriy Gapon wrote: >>>> 2. I am not sure if I like the approach of moving partition tasting code into >>>> common ZFS code (zfs.c). On one hand, it now makes sense because the new >>>> partition iteration code is machine-independent. On the other hand, the reason >>>> that I added arch_zfs_probe method was to give platforms full control over which >>>> partitions and in what order are probed. It seems to be important for some of them. >>>> So, I like how your new partition interface makes it much easier to ZFS-probe >>>> partitions, but I would prefer to have that code in arch_zfs_probe implementations >>>> rather than in zfs_probe_dev. >>> >>> From the other point of view, ZFS is not a just file system and it works >>> directly with disks and partitions. And it seems to me this code will be common >>> for other architectures. >> >> Well, it seems that you haven't yet touched sparc64_zfs_probe. > > Yes. It should work as before. Well, but it's obvious that zfs_probe_dev would be attempting to do some unneeded stuff (trying to treat partitions as disks) for that case. To me this is a clear indication zfs_probe_dev is not optimal for arch-independent implementation. So I still think that arch_zfs_probe should decide what disks and partitions to probe, and zfs_probe_dev should only probe what it's given and not try to be any smarter. But I've repeated myself three times already :-) > But if Marius can suggest how to change ofw_disk.c to get disk size and sector size, > then i will be able to break something here :) > >> If you'll find that you don't have to use any ugly hacks there, then good. >> But my impression is that it would be easier to stick to the previous approach. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:01:00 2012 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 0301F1065904; Mon, 16 Jul 2012 12:01:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 986958FC1D; Mon, 16 Jul 2012 12:00:59 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 2D320B8027; Mon, 16 Jul 2012 16:00:54 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 27696B8024; Mon, 16 Jul 2012 16:00:54 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 20EEABA083; Mon, 16 Jul 2012 16:00:54 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id DE091BA07C; Mon, 16 Jul 2012 16:00:53 +0400 (MSK) Message-ID: <50040271.5000301@FreeBSD.org> Date: Mon, 16 Jul 2012 16:00:49 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Andriy Gapon References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> <5003F39D.6030808@FreeBSD.org> <5003F589.40603@FreeBSD.org> <5003F79E.1060706@FreeBSD.org> <5003FB9D.90909@FreeBSD.org> In-Reply-To: <5003FB9D.90909@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09929B86E2E15E68F7B5E8F9" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 12:01:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09929B86E2E15E68F7B5E8F9 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.07.2012 15:31, Andriy Gapon wrote: >> Yes. It should work as before. >=20 > Well, but it's obvious that zfs_probe_dev would be attempting to do som= e unneeded > stuff (trying to treat partitions as disks) for that case. To me this = is a clear > indication zfs_probe_dev is not optimal for arch-independent implementa= tion. So I > still think that arch_zfs_probe should decide what disks and partitions= to probe, > and zfs_probe_dev should only probe what it's given and not try to be a= ny smarter. > But I've repeated myself three times already :-) And we will have the same - several copies of the same code in each archi= tecture, which i have deleted... Sparc doesn't support DIOCGMEDIASIZE and DIOCGSECTORSIZE ioctls, so it will not check each partition, only fd that is passed to the zfs_pr= obe_dev. Currently there is only one problem with ZFS tasting, that can affect use= rs - now we taste each disk and partition, but in the my branch ZFS tastes onl= y disks and partitions with type "freebsd" and "freebsd-zfs". So if you have created = ZFS on top of MBR partition with type "ntfs", then loader will be unable to detect i= t. --=20 WBR, Andrey V. Elsukov --------------enig09929B86E2E15E68F7B5E8F9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJQBAJ1AAoJEAHF6gQQyKF6oxQH/1StRDHfuQD3PzWQZUcraIni meEi0RN+XneeWY6dJi0A4182cW9uP+sDXkClAYViUEBBjkYgq7bEpZ0sGbengiz/ U+jLooGgYS0K1KalIXkP4nke87OqVKeCr1cwat4fyUg0g1QOTHs9LF77HkQq3AgS Blzz4CHR7/J+nyhp6HIRF19zoIhiZKDMcfOEPjDsC4OrWynnsNR6GMJ1gFxpl/WH RVfMYW9/sux4ggB53HN9pm6+abOOtHFat34FX7nruooBLZJd+JdC8oEUlrWIPgIf 43j7irsAraj/+iQ75KrzKPSUr9i69Mk+mOylA3q7DThZKUjGDAVm70ojSsDl41w= =X6bX -----END PGP SIGNATURE----- --------------enig09929B86E2E15E68F7B5E8F9-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 15:40:35 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEDD0106564A; Mon, 16 Jul 2012 15:40:35 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3655D8FC14; Mon, 16 Jul 2012 15:40:35 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q6GFeW5V010292; Mon, 16 Jul 2012 17:40:33 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q6GFeWpu010291; Mon, 16 Jul 2012 17:40:32 +0200 (CEST) (envelope-from marius) Date: Mon, 16 Jul 2012 17:40:32 +0200 From: Marius Strobl To: "Andrey V. Elsukov" Message-ID: <20120716154032.GA63893@alchemy.franken.de> References: <4FE9B01C.30306@yandex.ru> <5003EBAB.6030507@FreeBSD.org> <5003F39D.6030808@FreeBSD.org> <5003F589.40603@FreeBSD.org> <5003F79E.1060706@FreeBSD.org> <5003FB9D.90909@FreeBSD.org> <50040271.5000301@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50040271.5000301@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers , Marius Strobl , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code 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, 16 Jul 2012 15:40:35 -0000 On Mon, Jul 16, 2012 at 04:00:49PM +0400, Andrey V. Elsukov wrote: > On 16.07.2012 15:31, Andriy Gapon wrote: > >> Yes. It should work as before. > > > > Well, but it's obvious that zfs_probe_dev would be attempting to do some unneeded > > stuff (trying to treat partitions as disks) for that case. To me this is a clear > > indication zfs_probe_dev is not optimal for arch-independent implementation. So I > > still think that arch_zfs_probe should decide what disks and partitions to probe, > > and zfs_probe_dev should only probe what it's given and not try to be any smarter. > > But I've repeated myself three times already :-) > > And we will have the same - several copies of the same code in each architecture, > which i have deleted... > > Sparc doesn't support DIOCGMEDIASIZE and DIOCGSECTORSIZE ioctls, > so it will not check each partition, only fd that is passed to the zfs_probe_dev. > > Currently there is only one problem with ZFS tasting, that can affect users - > now we taste each disk and partition, but in the my branch ZFS tastes only disks and > partitions with type "freebsd" and "freebsd-zfs". So if you have created ZFS on top > of MBR partition with type "ntfs", then loader will be unable to detect it. > Sorry, I'm missing the big picture of ZFS support in the loader and currently unfortunately don't have the time to look into it or your patches. I don't think there's a way to determine the media and sector sizes without actually looking at the Sun and/or VTOC8 labels though. As for zfs_probe_dev, some user recently indicated that on sparc64 we should rather look at the disk devices listed in the "boot-device" environment variable in order to mimic what Solaris does rather than trying to probe anything that might be a disk device, mimicking what the FreeBSD/i386 ZFS loader does. Maybe that's a hint whether a arch_zfs_probe should exist. I can test patches once you guys have figures out how things should work though. Marius From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:01:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46F4C106566B for ; Mon, 16 Jul 2012 22:01:19 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 084D48FC12 for ; Mon, 16 Jul 2012 22:01:18 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6GLfgJH077490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jul 2012 14:41:42 -0700 (PDT) Message-ID: <50048A96.5060803@jetcafe.org> Date: Mon, 16 Jul 2012 14:41:42 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> In-Reply-To: <4FF55864.8040807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Pull in upstream before 9.1 code freeze? 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, 16 Jul 2012 22:01:19 -0000 On 07/05/12 02:03, Doug Barton wrote: > On 07/05/2012 01:28, Peter Jeremy wrote: >> On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown >> wrote: >>> As for the idea that Linux refugees need extra help to migrate, >>> that's the sort of thinking that led to things like: >>> >>> alias dir=ls >> >> Whilst we're on the subject, can we please also have #define BEGIN >> { #define END } wired into gcc to help people migrating from Algol >> and Pascal. > > Um, this kind of elitist crap really isn't helpful. > > If the new feature gets created, and you don't want to use it, turn it > off. No problem. > > I appreciate the people who've spoken up as to why they wouldn't want > to use it, but I haven't seen anything yet that says "having this > feature is a universally bad idea." Why not create a command wtf(1)? When you type it, it detects the shell you are using, looks at the last command you typed, and provides all sorts of arbitrarily verbose and usable documentation and suggestions as to what that command might have done, what the verbatim command will do, and where you can find more information. So a very brief example command flow might be: # lsof -p 8646 lsof: command not found # wtf I see you just tried to use the command 'lsof'. This command is not installed. If you want this command, there is a port for that which you can install by doing this (as root): cd /usr/ports/sysutils/lsof make install Alternatively you can type man fstat for the FreeBSD native equivalent for this functionality. Commands which are similar include: ls lshal lsvfs For more information on this wtf entry, or to suggest changes see this link: http://wtf.freebsd.org/command/8/lsof If you want to speak to a human who might know, try this mailing list: freebsd-questions@freebsd.org # I think this might appeal to both camps, and allows people the sublime pleasure of telling new users to type 'wtf' if they have an issue with a command. I'm not married to the name or even the idea. But I'd like to see someone explain why this isn't a valid solution to both sides. :D -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A solved problem is as useful to the mind as a broken sword on a battlefield. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:16:08 2012 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 B986B1065674 for ; Mon, 16 Jul 2012 22:16:08 +0000 (UTC) (envelope-from brodbd@uw.edu) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4998FC17 for ; Mon, 16 Jul 2012 22:16:08 +0000 (UTC) Received: by vbmv11 with SMTP id v11so4877796vbm.13 for ; Mon, 16 Jul 2012 15:16:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=yxEt22LiNHuU0EtyMbI9T9RhgPimpjKeUI9gfk4Vsso=; b=lVoI9WBJ+1XYs7eDBYcKunHFPBM86jLiQ4EtQMD56cDFi6at4nrJ5THkN+58kA8eHt d0BOxaUH+BHeDYdBU9fdq4H5gAVS+lhuY3YF0MDS8c7DdTF6Ri4PVtuyMRzQvwAAkDBm pZhvGE8HbeiURencSNLPy4WSrZ6mnv7iLYvXHcZ3JCKMLN3fW59miQU1jWmF7KdoXdsW vj4EnLKB4+Ckzcymr+EhWqhUgvQKdLBPxqzGq03PvcjDfbn6f+A8wSR8K6WTbTUCqJPu sX2IhuqpqKlszad8XpRzyIh+ebmxmF4v9ZHwr/UPxODt3TDuQLxqzrHa3C+SA8rivd13 LEPA== MIME-Version: 1.0 Received: by 10.220.204.212 with SMTP id fn20mr8601vcb.43.1342476967412; Mon, 16 Jul 2012 15:16:07 -0700 (PDT) Received: by 10.58.73.138 with HTTP; Mon, 16 Jul 2012 15:16:07 -0700 (PDT) In-Reply-To: <50048A96.5060803@jetcafe.org> References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <50048A96.5060803@jetcafe.org> Date: Mon, 16 Jul 2012 15:16:07 -0700 Message-ID: From: David Brodbeck To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVZL2UepRVheHTw6BbUwyChQvyh3IeHkSqyeWHzediWuPE0pRL2b8FMDzjyQDVddIY4n9C Subject: Re: Pull in upstream before 9.1 code freeze? 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, 16 Jul 2012 22:16:08 -0000 On Mon, Jul 16, 2012 at 2:41 PM, Dave Hayes wrote: > Why not create a command wtf(1)? > > When you type it, it detects the shell you are using, looks at the last > command you typed, and provides all sorts of arbitrarily verbose and usable > documentation and suggestions as to what that command might have done, what > the verbatim command will do, and where you can find more information. I suspect you meant this as a sarcastic suggestion, but I actually like it. It reminds me of AmigaDOS's "why" command, which would give a detailed explanation of why the previous command failed. -- David Brodbeck System Administrator, Linguistics University of Washington From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:34:14 2012 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 BF643106564A for ; Mon, 16 Jul 2012 22:34:14 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 998C48FC08 for ; Mon, 16 Jul 2012 22:34:14 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6GMYEgr078255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jul 2012 15:34:14 -0700 (PDT) Message-ID: <500496E6.9030008@jetcafe.org> Date: Mon, 16 Jul 2012 15:34:14 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <50048A96.5060803@jetcafe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Pull in upstream before 9.1 code freeze? 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, 16 Jul 2012 22:34:14 -0000 On 07/16/12 15:16, David Brodbeck wrote: > I suspect you meant this as a sarcastic suggestion, but I actually > like it. It reminds me of AmigaDOS's "why" command, which would give > a detailed explanation of why the previous command failed. Actually I meant this as a real suggestion, though I'll admit tainting it with some humor. :) -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< People sell talking parrots for huge sums. They never pause to compare the possible value of a thinking parrot. - Mulla Nasrudin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 05:45:54 2012 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 A57ED1065677 for ; Tue, 17 Jul 2012 05:45:54 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 1211F8FC14 for ; Tue, 17 Jul 2012 05:45:53 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6H5jp62009463; Tue, 17 Jul 2012 07:45:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6H5joie009460; Tue, 17 Jul 2012 07:45:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 17 Jul 2012 07:45:50 +0200 (CEST) From: Wojciech Puchar To: Dave Hayes In-Reply-To: <50048A96.5060803@jetcafe.org> Message-ID: References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <50048A96.5060803@jetcafe.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 17 Jul 2012 07:45:51 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 05:45:54 -0000 > Why not create a command wtf(1)? > there are really lot of good features that can be made in FreeBSD. actually good, instead of that crap From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 06:03:16 2012 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 C6544106564A; Tue, 17 Jul 2012 06:03:16 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 121728FC14; Tue, 17 Jul 2012 06:03:15 +0000 (UTC) Received: by lbon10 with SMTP id n10so208792lbo.13 for ; Mon, 16 Jul 2012 23:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQSELrt8brOetp6tnq4nqSlgLLQaH7zTcdGHKvkojaw=; b=mVI9fNBeIUkmY3Y1mAl7XFFtPswARDLLwogZ746g30BojycpGBwuvciJQ+zokPqxGN cPId/TQTJRiTDlXBXWud/839X0qg72E7Ro885p/rtAIZ1qvaobD6SIsvobSCAD14tVfl GBdb3E/RZ0za3iLe0/yVhujwjcYF7L/MoZ3LDNJ4g+4XQxmkbhI4X31CLe+3wSExKfnC RLmz9RBkkb5ox+9oz18X70kaJmd2HGJNIRnBQJ3QhK1Ee/lrbLty528EBeQZn3XhZFEI 9terNdT8j7oiBovddBoIerdy00HfS9JrDLGcoqMd+sdel5lSkucU0DyYOiglN/HR7oBe dq8w== MIME-Version: 1.0 Received: by 10.112.54.100 with SMTP id i4mr566357lbp.97.1342504995036; Mon, 16 Jul 2012 23:03:15 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Mon, 16 Jul 2012 23:03:14 -0700 (PDT) In-Reply-To: References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Tue, 17 Jul 2012 02:03:14 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. 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, 17 Jul 2012 06:03:17 -0000 Hi, On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe wrote: > Hi, > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: >> [..] >> Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. >> > I will just pass function pointers for now, if things should be done > dirty, let's be explicit about it. > > Now, the hinted device attachment did work quite smoothly, however, I > would have a few suggestion: > 1) add a call to bus_enumerate_hinted_children() before the call > DEVICE_IDENTIFY() call in bus_generic_driver_added() > > this is required to be able to support dynamic loading and attachment > of hinted children. > > 2) have a generic bus_hinted_child method which would just add a new > child to the bus. > > 3) have bus_enumerate_hinted_children() and bus_generic_attach() > always ran on device attachment. > > There is current +100 explicit call to bus_generic_attach() in the > sys/dev/ tree. This should be done always and implicitly. > > 4) have bus_generic_detach() always ran prior to device detachment > > If not already the case. There is still the same +100 direct call to > bus_generic_detach is the tree. > > 5) have the bus_generic_* method be the default of their respective method > > 6) have device_delete_child() called upon device detachment. > > As a rule of thumb, when a kld is unloaded there should not be any > remains of anything built previously. Without device_delete_child() or > proper singleton implementation, multiple load/unload sequence of bus > will attempt to attach multiple version of a child, even if the single > child was added prior to the bus_generic_attach() call. > > Also, as a rule of thumb, if the same logic is implemented in more > than a few buses, it should be made generic and implicit. > > I am lazy, I hate doing the same things over and over, not to say it > raised the likelihood of bugs' introduction... > could I at least get some feedback on the proposals above ? Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 09:22:15 2012 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 637F81065670 for ; Tue, 17 Jul 2012 09:22:15 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa13.ono.com (smtp13.ono.com [62.42.230.16]) by mx1.freebsd.org (Postfix) with ESMTP id E737F8FC0A for ; Tue, 17 Jul 2012 09:22:14 +0000 (UTC) Received: from GogPortatil.retena.com (85.219.45.167) by resmaa13.ono.com (8.5.113) (authenticated as nec556@retena.com) id 4FA882720124B385 for freebsd-hackers@freebsd.org; Tue, 17 Jul 2012 11:22:08 +0200 Message-ID: <4FA882720124B385@> (added by postmaster@resmaa13.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2012 11:25:02 +0200 To: freebsd-hackers@freebsd.org From: Eduardo Morras In-Reply-To: <20120705131518.06898223@bhuda.mired.org> References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <4FF5BE93.4010509@my.gd> <20120705170944.GA43725@DataIX.net> <20120705131518.06898223@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: AVG for E-mail 2012.0.2197 [2437/5135] Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 09:22:15 -0000 At 19:15 05/07/2012, Mike Meyer wrote: >On Thu, 5 Jul 2012 13:09:44 -0400 >Jason Hellenthal wrote: > > On Thu, Jul 05, 2012 at 06:19:31PM +0200, Damien Fleuriot wrote: > > > As long as it can be toggled off system-wide, persistently (sysctl?),= I > > > can't see the harm in bringing that in. > > Haha sysctl... thats going quite a bit too far into the system for this. > >Yup. A sysctl (or rc.conf variable) intended specifically to control >the behavior of shells is an even worse idea than turning this nanny >behavior on for everyone. Add sysctl for apps is a no-no, sysctl is for=20 system control, not userland control. The rc.conf=20 is not for that neither, it has system wide=20 configuration, not app specific config. The best solution (for me) is leave sh untouched=20 without this functionality. Fork it and make a=20 sh++ port with this (and more) functionality ,=20 install it and use it. Is it really too much work=20 to change your default (non-root) shell? I use zsh f.ex. Take care, if you start the system in rescue mode=20 or singleuser mode, will the new "hook" feature=20 search the unmounted partitions for ports info?=20 will it connect to internet for that? will fail miserably? > 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 28A321065672 for ; Tue, 17 Jul 2012 09:25:44 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 7F23D8FC18 for ; Tue, 17 Jul 2012 09:25:43 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6H9PeP4026883; Tue, 17 Jul 2012 11:25:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6H9PexG026880; Tue, 17 Jul 2012 11:25:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 17 Jul 2012 11:25:40 +0200 (CEST) From: Wojciech Puchar To: Eduardo Morras In-Reply-To: <4FA882720124B385@> (added by postmaster@resmaa13.ono.com) Message-ID: References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <4FF5BE93.4010509@my.gd> <20120705170944.GA43725@DataIX.net> <20120705131518.06898223@bhuda.mired.org> <4FA882720124B385@> (added by postmaster@resmaa13.ono.com) 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 17 Jul 2012 11:25:40 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 09:25:44 -0000 >> the behavior of shells is an even worse idea than turning this nanny >> behavior on for everyone. > > Add sysctl for apps is a no-no, sysctl is for system control, not userland still this stupid idea topics continue? Is FreeBSD finally intended to be unix implementation or feature war with linux/windows? STOP IT. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 11:21:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DADC41065673 for ; Tue, 17 Jul 2012 11:21:19 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa14.ono.com (smtp14.ono.com [62.42.230.176]) by mx1.freebsd.org (Postfix) with ESMTP id 698CA8FC15 for ; Tue, 17 Jul 2012 11:21:19 +0000 (UTC) Received: from GogPortatil.retena.com (85.219.45.167) by resmaa14.ono.com (8.5.113) (authenticated as nec556@retena.com) id 4FA8828001255B27 for freebsd-hackers@freebsd.org; Tue, 17 Jul 2012 13:15:37 +0200 Message-ID: <4FA8828001255B27@> (added by postmaster@resmaa14.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2012 13:18:30 +0200 To: freebsd-hackers@freebsd.org From: Eduardo Morras In-Reply-To: References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <4FF5BE93.4010509@my.gd> <20120705170944.GA43725@DataIX.net> <20120705131518.06898223@bhuda.mired.org> <4FA882720124B385@> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: AVG for E-mail 2012.0.2197 [2437/5135] Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 11:21:20 -0000 At 11:25 17/07/2012, Wojciech Puchar wrote: >>>the behavior of shells is an even worse idea than turning this nanny >>>behavior on for everyone. >> >>Add sysctl for apps is a no-no, sysctl is for system control, not userland > >still this stupid idea topics continue? Is FreeBSD finally intended >to be unix implementation or feature war with linux/windows? Of course it continues. There must be one site for each thing, that way i (we) only search where it is and not where perhaps it should be. I suppouse that you want sendmail configuration on sysctl? Not all, only some config lines, other lines can be on rc.conf, sendmail.conf, maild.conf and 30 more conf files. It's better than having only one. There will be conflicts, changes between minor release of where is what, but, hey!! it's the way you want it. >STOP IT. NO. And i can write with bigger uppercase letters than you ;) L From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 12:52:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93A57106564A for ; Tue, 17 Jul 2012 12:52:59 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A93C8FC08 for ; Tue, 17 Jul 2012 12:52:59 +0000 (UTC) Received: by qaat11 with SMTP id t11so213686qaa.13 for ; Tue, 17 Jul 2012 05:52:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version:x-gm-message-state; bh=nvi6Xpb64wiQbee2a4eUm3Nv1Z3dV88UBuXIPAmLYwU=; b=E9hB5jCeqRkDbLc+/dNJnaVsam9UMryPQlUDdWoj9GqTtOKuTrt4w1xAg+PFwE5OoL hFl6rw//3o7bres+Hrd79tvZztjQvYdiEa4PUG8rZ2+lrFMGL4MLXq+RLOLVzAFBYe8t wmhJ/DLvtsL7stUyePTckR9JutzuXAMSbiH2bZHogdsuHCNz6wQ74wCR3keGNLT6lOvv dUzq6Q59FzwfrQK/roXboCrgZ2sYM5XxjjLnbgNb0rAdMo2tdIIpMlTQjykozsS4IcaN sdxy0vqK6fkxfHTh3cUldEHHTiHJmmeFHvRXQqwLhv2LxwhNssY9nyZ3HNSZw/VzXqac 9w3A== Received: by 10.224.39.131 with SMTP id g3mr4378660qae.57.1342529573344; Tue, 17 Jul 2012 05:52:53 -0700 (PDT) Received: from [97.21.161.97] (97.sub-97-21-161.myvzw.com. [97.21.161.97]) by mx.google.com with ESMTPS id cz12sm26536279qab.5.2012.07.17.05.52.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 05:52:52 -0700 (PDT) From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: <3A0E5AB0-812D-433B-B2E8-DBD7B9124E85@longcount.org> Date: Tue, 17 Jul 2012 08:52:40 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQkzgIGCXm+/E5x3KWrCQ0VogNuCrYFgTiaxmKbGOUWfbJdHBTn9bSb9qN/IwWPO8bNnSnuQ Subject: Using mcelog 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, 17 Jul 2012 12:52:59 -0000 All I wanted to see how users of mcelog were implementing it on FreeBSD . My L= inux servers tend to run it via cron hourly and dump the results to syslog o= r a local log file . For now I am going to make a similar setup . Does using= it as a daemon provide anything running it via cron can't ? Are there any o= ptions to stay away from , Linux only options etc ? Also does anyone know wh= at options there are for FreeBSD on sparc ? =20 --- Mark saad | mark.saad@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 18:21:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17557106564A for ; Tue, 17 Jul 2012 18:21:55 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id E51A38FC17 for ; Tue, 17 Jul 2012 18:21:54 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6HILrNI094043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 11:21:54 -0700 (PDT) Message-ID: <5005AD41.6020406@jetcafe.org> Date: Tue, 17 Jul 2012 11:21:53 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF4BEED.10103@FreeBSD.org> <62039A45-92E4-4588-988D-6DF39D7B01E5@bsdimp.com> <201207050922.25815.j.mckeown@ru.ac.za> <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> <50048A96.5060803@jetcafe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 18:21:55 -0000 On 07/16/12 22:45, Wojciech Puchar wrote: >> Why not create a command wtf(1)? >> > there are really lot of good features that can be made in FreeBSD. > actually good, instead of that crap Unless you have some objective, measurable, and quantifiable definition of "crap", your judgement is a subjective one and I am unable to evaluate whether I am for or against it. I find that it's a real problem finding good features in FreeBSD, especially if they are new. I don't have so much time to track mailing lists and pour over the source code (usually the single source of documentation on new features), so I would find a command that suggested new features and pointed the user to related documentation extremely useful. I'm sure there are many others who would agree. :) Would you explain why you do not? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< The difference between a moral man and a man of honor is that the latter regrets a discreditable act, even when it has worked and he has not been caught. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 18:57:36 2012 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 BF97B1065678 for ; Tue, 17 Jul 2012 18:57:36 +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 658E08FC1D for ; Tue, 17 Jul 2012 18:57:36 +0000 (UTC) Received: (qmail 14629 invoked by uid 0); 17 Jul 2012 18:32:22 -0000 Received: from 67.206.185.131 by rms-us018 with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 17 Jul 2012 14:32:19 -0400 From: "Dieter BSD" Message-ID: <20120717183221.298430@gmx.com> MIME-Version: 1.0 To: freebsd-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: 4sp3cPcV3zOlNR3dAHAh38R+IGRvb0DK Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 18:57:36 -0000 >> Why not create a command wtf(1)? >> > there are really lot of good features that can be made in FreeBSD. > actually good, instead of that crap While this is certainly not the most important improvement that could be made (Fix the PRs!), the proposed wtf command could be useful. And, importantly, putting this functionality into a seperate utility is the correct way to do it. We don't want to add more complexity to the shell for several good reasons (bloat, possiblilty of bugs, slowness after every typo, not the Unix way[1], etc.). [1] "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features." http://www.faqs.org/docs/artu/ch01s06.html From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 19:35:11 2012 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 9C382106564A for ; Tue, 17 Jul 2012 19:35:11 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 418C98FC0C for ; Tue, 17 Jul 2012 19:35:11 +0000 (UTC) Received: by qcsg15 with SMTP id g15so635335qcs.13 for ; Tue, 17 Jul 2012 12:35:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:face:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=PUPSxmiG54u1t5QB1F5UIEAIzIvX9AtnRaMwArUkmUA=; b=SrLpG4KslDM7fPaDdYdKRl67wP1kC3z878wNdEnU7tdlHALyfB32OVueQTMt9MpqbL dwXurgMaEP8FqgrXUz3jj76KHwJZyk5IFomEUkgq+/7in+AkiHfKiDG27w+56lwWen+B zwINWYLxPLVoOttx+mdSwjGjywBsCv7uI4vB4GM2EgVrUeyRMlq0thf0gVACX+hYVgX1 YQrR+MH3a4ck13Y1q97X/GZ204HEj25VRH9BhAHKIt5keMe3baDBW0PMAB83F2CgeKB4 cXvWTC7ElAag40d+oFkvtlcM3m/HmUuRebTlb50u4mPxhpcf66vxDNQiZ/iFuc+r0sO7 tUFQ== Received: by 10.229.147.193 with SMTP id m1mr37927qcv.128.1342553710679; Tue, 17 Jul 2012 12:35:10 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id eb10sm27607777qab.4.2012.07.17.12.35.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 12:35:10 -0700 (PDT) Date: Tue, 17 Jul 2012 15:35:05 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20120717153505.42633535@bhuda.mired.org> In-Reply-To: <20120717183221.298430@gmx.com> References: <20120717183221.298430@gmx.com> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm2RBN3LlbZC4qPH5Y0Qte/1jRl73G74uZgYmK6mh08bZxgeTgCVmjbZCK+p+5efmWdKJia Subject: Re: Pull in upstream before 9.1 code freeze? 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, 17 Jul 2012 19:35:11 -0000 On Tue, 17 Jul 2012 14:32:19 -0400 "Dieter BSD" wrote: > >> Why not create a command wtf(1)? > > there are really lot of good features that can be made in FreeBSD. > > actually good, instead of that crap > While this is certainly not the most important improvement that could > be made (Fix the PRs!), the proposed wtf command could be useful. And it's been suggested a number of times on this thread. The proposed path is: 1) Write the WTF (or portsearch, or ...) command that can take a command name and return a list of suggested ports. Make it a port, since that's pretty much a zero-resistance move. 2) Add code to the port to use the *existing* hooks in some of the shells in ports (bash and zsh both have this, for instance) to invoke said command appropriately when they hit a command-not-found error. 3) Let people evaluate and play with that. 4) Now decide if we want this command in the base system. If the answer is mostly no, stop here. 5) Propose a patch to your favorite shell in the base system so the functionality added in step 2 will work in it as well. I'm not going to do this - this is the kind of thing that makes me loathe Linux. But if you want this functionality in your/the base system, your first step is clear - write the WTF program! Until that exists, the rest is just pointless debating. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 20:56:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6541D1065672 for ; Tue, 17 Jul 2012 20:56:34 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 393EF8FC19 for ; Tue, 17 Jul 2012 20:56:34 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6HKuXOQ096401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 13:56:33 -0700 (PDT) Message-ID: <5005D181.8080709@jetcafe.org> Date: Tue, 17 Jul 2012 13:56:33 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> In-Reply-To: <20120717153505.42633535@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 17 Jul 2012 20:56:34 -0000 On 07/17/12 12:35, Mike Meyer wrote: > I'm not going to do this - this is the kind of thing that makes me > loathe Linux. But if you want this functionality in your/the base > system, your first step is clear - write the WTF program! Until that > exists, the rest is just pointless debating. I think this is unintentionally specious reasoning. No offense intended. :) The program itself is fairly trivial to write. It's the -content- that is important to the perceived usability of the tool. I do not believe the content can be written by one person alone; this would be a community effort. Without the content, most everyone will declare the tool useless, the experiment a failure, and it will be business as usual. So it's really not possible to write the tool and associated documentation "myself". Otherwise I would. The "pointless debating" is really an attempt to get a critical mass of knowledgeable developers to agree to participate in creating this tool. There seems to be an equal and opposing mass that feels we should dig for this information ourselves and the existence of a helpful tool to do this is a blight on the operating system. The problem actually has a deeper idea, and this is why I changed the subject line. I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. Perception is usually subjective, and I'm not going to try to prove this or claim objective truth here...I could very well be objectively incorrect. Perhaps it's more general; it seems to me at best that this community resists documentation and explanation in the general case. Some sources of this are: I rarely read the handbook and find that the procedures or tools work as advertised, or that there wasn't some better tool or idea I "should have just known to do". I likely miss some best practices because...the information is not out there and sometimes asking anything is met with stoic silence (e.g. how does libgeom work, especially the XML stuff...for that matter a good detailed document on geom(8) with examples and best practices ). This perception troubles me because, at least in my mind, a good developer also documents the work and provides some sort of link or summary for people who are running production or near-production systems. I really don't understand why I have this perception, nor is it logical that the perception should exist in the first place. It remains nonetheless. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Nasrudin was sitting talking with a friend as dusk fell. "Light a candle", the man said, "because it is dark now. There is one just by your left side." "How can I tell my right from my left in the dark, you fool?" came the reply. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 21:28:34 2012 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 56310106564A for ; Tue, 17 Jul 2012 21:28:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 341468FC08 for ; Tue, 17 Jul 2012 21:28:34 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id D146A56252; Tue, 17 Jul 2012 16:28:28 -0500 (CDT) Date: Tue, 17 Jul 2012 16:28:28 -0500 From: Mark Linimon To: Dave Hayes Message-ID: <20120717212828.GA21825@lonesome.com> References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5005D181.8080709@jetcafe.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Tue, 17 Jul 2012 21:54:02 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 17 Jul 2012 21:28:34 -0000 On Tue, Jul 17, 2012 at 01:56:33PM -0700, Dave Hayes wrote: > I've been using FreeBSD since the 90s. My perception (over many > years of observation) is that the FreeBSD people most able to > document what exists and how to use it seem to also have the > greatest resistance to writing any documentation. I'll just note that over the past ~6 months, the documentation team has seen a lot of new contributors and new energy. So from my view, the situation is improving. mcl From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 22:14:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 904D41065670 for ; Tue, 17 Jul 2012 22:14:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 171A11584D1; Tue, 17 Jul 2012 22:14:04 +0000 (UTC) Message-ID: <5005E3AC.7050001@FreeBSD.org> Date: Tue, 17 Jul 2012 15:14:04 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dave Hayes References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> In-Reply-To: <5005D181.8080709@jetcafe.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 17 Jul 2012 22:14:13 -0000 On 07/17/2012 01:56 PM, Dave Hayes wrote: > I've been using FreeBSD since the 90s. My perception (over many years of > observation) is that the FreeBSD people most able to document what > exists and how to use it seem to also have the greatest resistance to > writing any documentation. Writing code is more fun than documenting it. People who are good at documenting other people's code usually go down 2 paths ... either they become very good at it and expect to be well paid for their services, or they realize that writing code is more fun than documenting it. That said, historically as a project we have placed very high value on attracting people who are good at writing good code, and not placed a high value on documentation. That's not to say that we don't value the people who *do* write our documentation, but if it comes to a choice between good code with no documentation, or no code, we have historically chosen the former. This is true to the extent that when I suggested to a new committer that they should have waited to add a new project until the man pages were written I got torn a new one by my fellow committers, and told that I was 'discouraging contributions' and 'bad for morale.' > Perception is usually subjective, and I'm not > going to try to prove this or claim objective truth here...I could very > well be objectively incorrect. Perhaps it's more general; it seems to me > at best that this community resists documentation and explanation in the > general case. Resistance is not accurate. Indifference is a better description. > Some sources of this are: I rarely read the handbook So now that we've discussed *our* shortcomings, let's discuss yours. :) Read the handbook. Seriously. The FAQ is stale, and needs attention, but the FreeBSD Handbook is top-quality stuff. It has some cobwebby bits, and if you find them, file PRs to bring it to our attention. But you can't on one hand say that we resist documentation, and then on the other hand admit that you haven't read our most important example. > ... and sometimes > asking anything is met with stoic silence (e.g. how > does libgeom work, especially the XML stuff...for that matter a good > detailed document on geom(8) with examples and best practices ). So we're back to the area where we are indeed weak. I have pushed and pushed (both privately and publicly) for us to get better in this area, and am constantly told that what I'm asking for is foolish and/or unnecessary. We really do need better design documents, and plans to change critical parts of the system should be better documented in advance. But frankly, this is incredibly unlikely to happen without a major change in the values system of the project as a whole; and the last core election made it pretty clear that it's not likely to happen any time soon. > This perception troubles me because, at least in my mind, a good > developer also documents the work and provides some sort of link or > summary for people who are running production or near-production > systems. I really don't understand why I have this perception, nor is it > logical that the perception should exist in the first place. Not only is the perception reasonable, but the process of writing out such documentation (different from handbook-style docs, or even man pages) often helps clarify both the actual proposed design, and the current state of things. It's a shame that we don't have a culture that not only encourages this, but requires it. However, we don't; and aren't ever likely to. Doug From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 22:38:28 2012 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 5847D106566C for ; Tue, 17 Jul 2012 22:38:28 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 36B1B8FC15 for ; Tue, 17 Jul 2012 22:38:28 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6HMcLKX097858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 15:38:22 -0700 (PDT) Message-ID: <5005E95D.2010502@jetcafe.org> Date: Tue, 17 Jul 2012 15:38:21 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> <5005E3AC.7050001@FreeBSD.org> In-Reply-To: <5005E3AC.7050001@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 17 Jul 2012 22:38:28 -0000 On 07/17/12 15:14, Doug Barton wrote: >> Some sources of this are: I rarely read the handbook > > So now that we've discussed *our* shortcomings, let's discuss yours. :) > Read the handbook. Seriously. I should have written that better. I *do* read the handbook; check the conjunction. I said: "I rarely read the handbook *and* find that the procedures or tools as advertised" -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< "Every extreme attitude is a flight from the self." -- Eric Hoffer From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 22:41:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 48D1B106564A for ; Tue, 17 Jul 2012 22:41:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8939A14E796; Tue, 17 Jul 2012 22:41:57 +0000 (UTC) Message-ID: <5005EA35.40600@FreeBSD.org> Date: Tue, 17 Jul 2012 15:41:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dave Hayes References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> <5005E3AC.7050001@FreeBSD.org> <5005E95D.2010502@jetcafe.org> In-Reply-To: <5005E95D.2010502@jetcafe.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 17 Jul 2012 22:41:58 -0000 On 07/17/2012 03:38 PM, Dave Hayes wrote: > On 07/17/12 15:14, Doug Barton wrote: >>> Some sources of this are: I rarely read the handbook >> >> So now that we've discussed *our* shortcomings, let's discuss yours. :) >> Read the handbook. Seriously. > > I should have written that better. I *do* read the handbook; check the > conjunction. I said: > > "I rarely read the handbook *and* find that the procedures or tools as > advertised" Ok, you're off the hook then. :) From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 03:17:32 2012 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 75CEA106566B for ; Wed, 18 Jul 2012 03:17:32 +0000 (UTC) (envelope-from willingbug@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 404BD8FC16 for ; Wed, 18 Jul 2012 03:17:32 +0000 (UTC) Received: by obbun3 with SMTP id un3so1948017obb.13 for ; Tue, 17 Jul 2012 20:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rEmtZ6L6vnwA0MnUmaXE3/HNWBMfPJlXv3lQSBaboyg=; b=PUADmNCUkaxYDFJsA1udVKCsqG0GE3K3iFXMVQDuQFNkBioJYwE8yUBdZngl2X3UCd Q44BEfunRW6OsCqWOGhrBdttJgsXR9jKCmMchSOEjSxDAyTqzMwSKIi1NTV8FY5MHa14 7VCGUyT68y8QaF5aKr8QCj2sH80NaaEkFsqF45bGINJYzitw6Y+ygs1BxFL/1Ekbaek/ ucPGFZQKVRs5e/LxZI7HwH+z5Ideq0zhdPLWr1AkDqwA6ML5ezU8YdVwt0qGz0qIomOy 0kZJ91EzXsj7DOTUFGX2EQSL1XOrHESTgwWL/eClx5MRd8kdboFTZZHLJsO+Aj86szMu av2Q== MIME-Version: 1.0 Received: by 10.182.212.98 with SMTP id nj2mr6843963obc.18.1342581451866; Tue, 17 Jul 2012 20:17:31 -0700 (PDT) Received: by 10.182.170.74 with HTTP; Tue, 17 Jul 2012 20:17:31 -0700 (PDT) Date: Wed, 18 Jul 2012 11:17:31 +0800 Message-ID: From: cz li To: freebsd-hackers Content-Type: text/plain; charset=UTF-8 Subject: Under FREEBSD network control. 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, 18 Jul 2012 03:17:32 -0000 I would like to build a bridge using FREEBSD system.At the same time, they can do the network traffic control.How to do it? thank you! From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 04:20:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3396106564A for ; Wed, 18 Jul 2012 04:20:04 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 856F38FC08 for ; Wed, 18 Jul 2012 04:20:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6I4Jw4U012828; Tue, 17 Jul 2012 22:20:02 -0600 From: Erich Dollansky To: freebsd-hackers@freebsd.org Date: Wed, 18 Jul 2012 11:18:19 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207181118.19562.erichfreebsdlist@ovitrap.com> Cc: cz li Subject: Re: Under FREEBSD network control. 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, 18 Jul 2012 04:20:11 -0000 Hi, On Wednesday 18 July 2012 10:17:31 cz li wrote: > I would like to build a bridge using FREEBSD system.At the same time, > they can do the network traffic control.How to do it? if I remember right, it is all in the handbook. You might also check man rc.conf and man ifconfig We will help you when you have some questions regarding the details. Erich From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 06:51:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8ADC1065673 for ; Wed, 18 Jul 2012 06:51:47 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from pikmeer.webweaving.org (pikmeer.webweaving.org [178.18.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0A48FC14 for ; Wed, 18 Jul 2012 06:51:46 +0000 (UTC) Received: from beeb-2.leiden.webweaving.org (5356CFB9.cm-6-7d.dynamic.ziggo.nl [83.86.207.185]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.5/8.14.5) with ESMTP id q6I6fT8I084282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jul 2012 06:41:30 GMT (envelope-from dirkx@webweaving.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1482\)) From: Dirk-Willem van Gulik In-Reply-To: Date: Wed, 18 Jul 2012 08:48:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41F75882-4FC4-4549-BF47-4E74C4D7A26E@webweaving.org> References: To: cz li X-Mailer: Apple Mail (2.1482) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (pikmeer.webweaving.org [178.18.23.51]); Wed, 18 Jul 2012 06:41:30 +0000 (UTC) Cc: freebsd-hackers Subject: Re: Under FREEBSD network control. 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, 18 Jul 2012 06:51:47 -0000 On 18 jul. 2012, at 05:17, cz li wrote: > I would like to build a bridge using FREEBSD system.At the same time, > they can do the network traffic control.How to do it? Check the handbook - or, easier, do 'man bridge' and see the last = example in the section 'examples'. Dw. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 08:29:39 2012 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 BB2BC106566B for ; Wed, 18 Jul 2012 08:29:39 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2114E8FC19 for ; Wed, 18 Jul 2012 08:29:38 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6I7jAJl004291; Wed, 18 Jul 2012 09:45:10 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6I7jAmO004288; Wed, 18 Jul 2012 09:45:10 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 18 Jul 2012 09:45:10 +0200 (CEST) From: Wojciech Puchar To: cz li 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 18 Jul 2012 09:45:10 +0200 (CEST) Cc: freebsd-hackers Subject: Re: Under FREEBSD network control. 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, 18 Jul 2012 08:29:39 -0000 > I would like to build a bridge using FREEBSD system.At the same time, > they can do the network traffic control.How to do it? read manuals > thank you! > _______________________________________________ > 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 Jul 18 08:36:46 2012 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 53A691065670 for ; Wed, 18 Jul 2012 08:36:46 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 950F58FC19 for ; Wed, 18 Jul 2012 08:36:45 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6I8aeQW004663; Wed, 18 Jul 2012 10:36:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6I8aek6004660; Wed, 18 Jul 2012 10:36:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 18 Jul 2012 10:36:40 +0200 (CEST) From: Wojciech Puchar To: Dave Hayes In-Reply-To: <5005D181.8080709@jetcafe.org> Message-ID: References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 18 Jul 2012 10:36:41 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 18 Jul 2012 08:36:46 -0000 > > I think this is unintentionally specious reasoning. No offense intended. :) > true > The program itself is fairly trivial to write. i don't need such a tool, but if it would be separate tool, then it is all right if someone like to write it. This would be unix way. > So it's really not possible to write the tool and associated documentation > "myself". Otherwise I would. The "pointless debating" is really an attempt to > get a critical mass of knowledgeable developers to agree to participate in not really. the idea was to integrate it with shell and turn on it by default, prefering newbies over norml users, and making another change that would actually prevent getting knowledge to newbie. > I've been using FreeBSD since the 90s. My perception (over many years of > observation) is that the FreeBSD people most able to document what exists and > how to use it seem to also have the greatest resistance to writing any > documentation. what do you mean? FreeBSD manual pages is what i consider great part. i mean manual pages. handbook is not always up to date but still fine for a NEW USER to learn FreeBSD. And that's the right way. "creators", "helpers" like proposed reminds me windows. A "Help" that doesn't really help learning anything. There are already lots of stupid things that is ALREADY done in FreeBSD without reason. Few examples: 1) XML output from some sysctl variables. It isn't just stupid. It's sad. 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. "Preventing people doing stupid things would prevent doing clever things". OK there is gpart now but still bsdlabel is far easier and useful. 3) replacing C compiler with immature one just because licencing is "better". Still - GCC licencing is fine for use in FreeBSD. 4) Adding features that are not really finished and in working state. gjournal is an example, background fsck is another (everyone actually ends in background_fsck=NO) and more that i don't probably get contact with. Of course in the same time where are hundreds of good things done, and we all know it. But if people won't understand a problem NOW and fight it, it will become worse. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 08:37:25 2012 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 2AD2C10657A4 for ; Wed, 18 Jul 2012 08:37:25 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 77B988FC22 for ; Wed, 18 Jul 2012 08:37:24 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6I8bJCO004670; Wed, 18 Jul 2012 10:37:19 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6I8bJ7v004667; Wed, 18 Jul 2012 10:37:19 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 18 Jul 2012 10:37:19 +0200 (CEST) From: Wojciech Puchar To: Mark Linimon In-Reply-To: <20120717212828.GA21825@lonesome.com> Message-ID: References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> <20120717212828.GA21825@lonesome.com> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 18 Jul 2012 10:37:20 +0200 (CEST) Cc: Dave Hayes , freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 18 Jul 2012 08:37:25 -0000 >> greatest resistance to writing any documentation. > > I'll just note that over the past ~6 months, the documentation team has > seen a lot of new contributors and new energy. So from my view, the > situation is improving. And is already great. The topic wasn't about documentation. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 10:17:35 2012 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 59CA61065670 for ; Wed, 18 Jul 2012 10:17:35 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D62568FC14 for ; Wed, 18 Jul 2012 10:17:34 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1268291bkc.13 for ; Wed, 18 Jul 2012 03:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LDbjIrdPG08V3xxsC4K5vS793RzLA8gcjP61J+NrU5k=; b=m8S3MZjiZ4yMmRWp7/6PN1sQOe4jnEEMcaMyae3JMJZ2fnykcT3OS7v3ZFdMrL345e 0MxEYCcGCyAYP3cNahc1f3tTfl3w5IVsqT0u53EtQtsaMW6sqCX8j1Dv/1FsExmo8azB ZSEgg0HraI/s+lmshqnmMEmLtP055oT7W6Z3zWVAJOz4RJHl4KAgqL/8zW5BM3cSYxB8 x2JGwSIgRs+DJodoen6uqXMGEJlqzvZDDdj7snhMIFumBdbJv4WmwAdJXvrbfXOE86zP MXtwziyc2dRhyaktEHL0dkGTLRAgjA1SlkL6TuuGG8hWiJ0ySUVgb0q/1tCCdT0Bqhi1 AMPw== MIME-Version: 1.0 Received: by 10.205.133.11 with SMTP id hw11mr1172601bkc.46.1342606653582; Wed, 18 Jul 2012 03:17:33 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Wed, 18 Jul 2012 03:17:33 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Wed, 18 Jul 2012 03:17:33 -0700 (PDT) In-Reply-To: References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> Date: Wed, 18 Jul 2012 11:17:33 +0100 Message-ID: From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dave Hayes , freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 18 Jul 2012 10:17:35 -0000 On 18 Jul 2012 09:39, "Wojciech Puchar" wrote: >> >> >> I think this is unintentionally specious reasoning. No offense intended. :) >> > true > > >> The program itself is fairly trivial to write. > > > i don't need such a tool, but if it would be separate tool, then it is all right if someone like to write it. This would be unix way. > > >> So it's really not possible to write the tool and associated documentation "myself". Otherwise I would. The "pointless debating" is really an attempt to get a critical mass of knowledgeable developers to agree to participate in > > > not really. the idea was to integrate it with shell and turn on it by default, prefering newbies over norml users, and making another change that would actually prevent getting knowledge to newbie. > > >> I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. > > > what do you mean? FreeBSD manual pages is what i consider great part. > > i mean manual pages. handbook is not always up to date but still fine for a NEW USER to learn FreeBSD. > > And that's the right way. > > "creators", "helpers" like proposed reminds me windows. A "Help" that doesn't really help learning anything. > > > There are already lots of stupid things that is ALREADY done in FreeBSD without reason. > > Few examples: > > 1) XML output from some sysctl variables. It isn't just stupid. It's sad. > 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. > > "Preventing people doing stupid things would prevent doing clever things". > > OK there is gpart now but still bsdlabel is far easier and useful. Bsdlabel was a monstrosity that required a calculator to hand to do anything useful. Gpart on the other hand is easily scriptable. Chris From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 19:46:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63E191065674 for ; Wed, 18 Jul 2012 19:46:39 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 23F8F8FC16 for ; Wed, 18 Jul 2012 19:46:39 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q6IJkcIt014834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2012 12:46:38 -0700 (PDT) Message-ID: <5007129E.6020701@jetcafe.org> Date: Wed, 18 Jul 2012 12:46:38 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 18 Jul 2012 19:46:39 -0000 On 07/18/12 01:36, Wojciech Puchar wrote: > not really. the idea was to integrate it with shell and turn on it by > default, prefering newbies over norml users, and making another change > that would actually prevent getting knowledge to newbie. I don't agree with modifying the shell either, and I really doubt that is going to happen here. >> I've been using FreeBSD since the 90s. My perception (over many years >> of observation) is that the FreeBSD people most able to document what >> exists and how to use it seem to also have the greatest resistance to >> writing any documentation. > > what do you mean? FreeBSD manual pages is what i consider great part. > > i mean manual pages. handbook is not always up to date but still fine > for a NEW USER to learn FreeBSD. > > And that's the right way. While I have learned much from man pages, as I remember hearing it explained to me...man pages are -reference- material. They are not intended to be the 'right way' to learn something, but instead as a quick reference guide. Of course, I doubt anyone can make a case for the 'one true right way' to learn FreeBSD. I would never teach someone to read the man pages as a way to familiarize themselves with...say...geom(8). (In fact, I'd love to find some better introductory/overview documentation for geom, but I digress.) The notion of a 'new user' is unfortunately too wide of a category to target documentation to. A secretary who's never seen anything but windows, a 5 year old child, and a fresh PhD in computer science might all fit this category. Each of these people requires different levels of teaching. Everytime I see these discussions my mind flashes to a web based wiki where everyone writes helpful information (like the Emacs Wiki) on various topics and it's fairly well indexed so you can see related ideas. Does something like this exist for FreeBSD? > 4) Adding features that are not really finished and in working state. > gjournal is an example, background fsck is another (everyone actually > ends in background_fsck=NO) Well you have me there, I thought background fsck worked...I just left it on because it's set like that in /etc/defaults/rc.conf. > Of course in the same time where are hundreds of good things done, and > we all know it. But if people won't understand a problem NOW and fight > it, it will become worse. If everyone is busy fighting evil, who is left to create the good? :) -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A free society is one where it is safe to be unpopular. -- Adlai Stevenson From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 20:26:59 2012 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 C9CB11065672 for ; Wed, 18 Jul 2012 20:26:59 +0000 (UTC) (envelope-from bcrisp@crispernetworks.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4343F8FC0C for ; Wed, 18 Jul 2012 20:26:59 +0000 (UTC) Received: by vcbf1 with SMTP id f1so1813391vcb.13 for ; Wed, 18 Jul 2012 13:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+JTwDrneCV5a+cGuJfIf+7yArooKQ9cVW0u8C/KWPuA=; b=GaRGQibUGbpF9IK7/fH5Pn/dwPqn3V4AxUdA71mPDVqkLPOpoaEn8xVba+hjla9EIc Vf0EgkY9LMCS6buF/3I10Au9K5UPMPBkS3PVq7YCDmbYItMMm+JcqJESwzeUevB5yr7/ myStSMhE2kGSI6ckc89y+0WUPb/kPEXe+MGoa0sp7kQl2L9wiSqiSdBin4vYJHhdYlXH 4THdW8xn4aVVDNrsTD+EzVEbGSoZlljrrjoOfd5Vd8n4NgJs1TyjS6T4Md2jm9AB032R icrTRr1QV4Cx6Kvi8MTEzyazlIDmM9Mm53ND3ObnbM3tGVsdsyzBzBYdfZeEBKIEgSXE UEtQ== MIME-Version: 1.0 Received: by 10.52.95.110 with SMTP id dj14mr382578vdb.69.1342643218130; Wed, 18 Jul 2012 13:26:58 -0700 (PDT) Received: by 10.58.216.6 with HTTP; Wed, 18 Jul 2012 13:26:57 -0700 (PDT) In-Reply-To: <4FFF4B95.9080105@delphij.net> References: <4FFF4B95.9080105@delphij.net> Date: Wed, 18 Jul 2012 16:26:57 -0400 Message-ID: From: Bill Crisp To: Xin Li X-Gm-Message-State: ALoCoQkFxcq4LBfSLxyq7Ciqn8jHQ3Z//yXDspoI4oyIptm6p5yBqvPOrolWVeK6KJYTPAX3ObsR Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.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: Wed, 18 Jul 2012 20:26:59 -0000 Xin, Thanks for the reply! Unfortunately I tried to put the code from the patch in place but there seems to be some missing functions in the header file and too many arguments to a function and some other errors below: ../../../amd64/amd64/trap.c: In function `syscall': ../../../amd64/amd64/trap.c:884: warning: implicit declaration of function `ksiginfo_init_trap' ../../../amd64/amd64/trap.c:884: warning: nested extern declaration of `ksiginfo_init_trap' ../../../amd64/amd64/trap.c:884: error: `ksi' undeclared (first use in this function) ../../../amd64/amd64/trap.c:884: error: (Each undeclared identifier is reported only once ../../../amd64/amd64/trap.c:884: error: for each function it appears in.) ../../../amd64/amd64/trap.c:886: error: `BUS_OBJERR' undeclared (first use in this function) ../../../amd64/amd64/trap.c:889: error: too few arguments to function `trapsignal' *** Error code 1 I can possibly take a stab at writing something to handle this...but I don't write in C very often and I am sure others are much more experienced in the FreeBSD kernel than I am. If anyone can help further please let me know. Thanks! On Thu, Jul 12, 2012 at 6:11 PM, Xin Li wrote: > On 07/12/12 09:36, Bill Crisp wrote: > >> Good Morning! >> >> This was also posted to the FreeBSD forums: >> >> I have been researching CVE-2012-0217 and while I have patched the kernels >> on servers with 7.3/8.2 that I have, I would like to see if anyone knows >> for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are >> out of support from looking at the documentation. I have looked at the >> code >> in trap.c to see if the current patch would work with 6.3 source but it >> won't based on what I saw. I am also aware of upgrading as an option to >> resolve this unfortunately in some cases I have this is not possible right >> now. >> > I believe that 6.x are vulnerable. You will have to backport the change > (something like this against sys/amd64/amd64/trap.c, in syscall() right > after > > PTRACESTOP_SC(p, td, S_PT_SCX); > > Add: > > + /* > + * If the user-supplied value of %rip is not a canonical > + * address, then some CPUs will trigger a ring 0 #GP during > + * the sysret instruction. However, the fault handler would > + * execute with the user's %gs and %rsp in ring 0 which would > + * not be safe. Instead, preemptively kill the thread with a > + * SIGBUS. > + */ > + if (td->td_frame->tf_rip>= VM_MAXUSER_ADDRESS) { > + ksiginfo_init_trap(&ksi); > + ksi.ksi_signo = SIGBUS; > + ksi.ksi_code = BUS_OBJERR; > + ksi.ksi_trapno = T_PROTFLT; > + ksi.ksi_addr = (void *)td->td_frame->tf_rip; > + trapsignal(td,&ksi); > + } > > Right before: > > WITNESS_WARN(...) > > > Cheers, > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 20:29:39 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6864E1065680; Wed, 18 Jul 2012 20:29:39 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF6A8FC1C; Wed, 18 Jul 2012 20:29:38 +0000 (UTC) Received: by vcbf1 with SMTP id f1so1815746vcb.13 for ; Wed, 18 Jul 2012 13:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=QFExc81APErBdIs7u7To+/i/0qb8mZa3lGwJI1upoI8=; b=lH5uIavT4Am9pFXjHtQWxJ/+0LP0cfR51BM4PvtdW0t9kcvUMqIiosamSGW+nmkZGj ISUfXtT1KeJjkVu99Lp/Asot2OXX9/H2kBDjrlfkFa4I8kDuT+JQEvrRu81mfBR4gkg3 2OCyHDYYlUtgOsXZ0xDEcmeh1GOiOJvQcJolBE8Hv7dOjh64ln0efNw97VKfRdMDK6aH a+BwNWEjQDqGO5VjxxcW8l8McXUksaBMyDXl4FdVWbw4qAS+GTm2y0ZTvUAeYq5TO39O WkCC+zFs3e+xFGqjkvE9/IpmpANYE0NcNDASJkQ+93CkBgo0GPM+391+nZ8QM9pgIq88 8PVQ== MIME-Version: 1.0 Received: by 10.220.107.136 with SMTP id b8mr1656236vcp.17.1342643378592; Wed, 18 Jul 2012 13:29:38 -0700 (PDT) Received: by 10.52.37.130 with HTTP; Wed, 18 Jul 2012 13:29:38 -0700 (PDT) Date: Wed, 18 Jul 2012 16:29:38 -0400 Message-ID: From: Ryan Stone To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin Subject: ULE scheduler miscalculates CPU utilization for threads that run in short bursts 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, 18 Jul 2012 20:29:39 -0000 At $WORK we use a modification of DEVICE_POLLING instead of running our NICs in interrupt mode. With the ULE scheduler we are seeing that CPU utilization (e.g. in top -SH) is completely wrong: the polling threads always end up being reported at a utilization of 0%. I see problems both with the CPU utilization algorithm introduced in r232917 as well as the original one. The problem with the original algorithm is pretty easy to explain: ULE was sampling for CPU usage in hardclock(), which also kicks off the polling threads, so samples are never taken when the polling thread was running. It appears that r232917 attempts to do time-based CPU accounting instead of sampling based. sched_pctcpu_update() is called at various places to update the CPU usage of each thread: static void sched_pctcpu_update(struct td_sched *ts, int run) { int t = ticks; if (t - ts->ts_ltick >= SCHED_TICK_TARG) { ts->ts_ticks = 0; ts->ts_ftick = t - SCHED_TICK_TARG; } else if (t - ts->ts_ftick >= SCHED_TICK_MAX) { ts->ts_ticks = (ts->ts_ticks / (ts->ts_ltick - ts->ts_ftick)) * (ts->ts_ltick - (t - SCHED_TICK_TARG)); ts->ts_ftick = t - SCHED_TICK_TARG; } if (run) ts->ts_ticks += (t - ts->ts_ltick) << SCHED_TICK_SHIFT; ts->ts_ltick = t; } The problem with it is that it only seems to work at the granularity of 1 tick. My polling threads get woken up at each hardclock() invocation and stop running before the next hardclock() invocation, so ticks is (almost) never incremented while the polling thread is running. This means that when sched_pctcpu_update is called when the polling thread is going to sleep, run=1 but ts->ts_ltick == ticks, so ts_ticks is incremented by 0. When the polling thread is woken up again, ticks has been incremented in the meantime and sched_pctcpu_update is called with run=0, so ts_ticks is not incremented but ltick is set to ticks. The effect is that ts_ticks is never incremented so CPU usage is always reported as 0. I think that you'll see the same effect with the softclock threads, too. I've experimented with reverting r232917 and instead moving the sampling code from sched_tick() to sched_clock(), and that seems to give me reasonably accurate results (for my workload, anyway). The other option would be to use a timer with a higher granularity than ticks in sched_pctcpu_update(). From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 20:47:30 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C76E9106566C for ; Wed, 18 Jul 2012 20:47:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 534228FC12 for ; Wed, 18 Jul 2012 20:47:30 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so4421060wgb.1 for ; Wed, 18 Jul 2012 13:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+8r9l+r0PjFu6OA68GewdF2xmFXWJ18S1sxCqan9deI=; b=SugkjUhyQ/UbdeCKx1OlKPedFbRN61g3+ZDN8fapSQ+f2WKZDEZ6xGQTbopcphyBMY LEaHiTdIAaue6ed/rBsU3nFa6hNHTSZ/mXxRXQiETHH/D9c/5+/VL88ESVYrp+SwaKjc VmCp4HryVEm0/edfW1dsb2u0g8y3Ge2Dne0m+ZVpIHtsgENYj7n21T3c6pntvwp0w0+S yj2duDgffYVqq2sI3nTynjCjMlGQCDCaxD9Ma+hUVH3cKlXHK5TuTMtlsFRVwheHWEJj hpzp3idmZokkkURqL54l1COq6wG9qeMMuJdtH2sU9cvnvlCs/DItmQQPzTKtVFPfPHVm OUcA== Received: by 10.180.78.33 with SMTP id y1mr9776401wiw.3.1342644449319; Wed, 18 Jul 2012 13:47:29 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id ef5sm158370wib.3.2012.07.18.13.47.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 13:47:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <500720DD.8090605@FreeBSD.org> Date: Wed, 18 Jul 2012 23:47:25 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: ULE scheduler miscalculates CPU utilization for threads that run in short bursts 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, 18 Jul 2012 20:47:31 -0000 On 18.07.2012 23:29, Ryan Stone wrote: > At $WORK we use a modification of DEVICE_POLLING instead of running > our NICs in interrupt mode. With the ULE scheduler we are seeing that > CPU utilization (e.g. in top -SH) is completely wrong: the polling > threads always end up being reported at a utilization of 0%. > > I see problems both with the CPU utilization algorithm introduced in > r232917 as well as the original one. The problem with the original > algorithm is pretty easy to explain: ULE was sampling for CPU usage in > hardclock(), which also kicks off the polling threads, so samples are > never taken when the polling thread was running. > > It appears that r232917 attempts to do time-based CPU accounting > instead of sampling based. sched_pctcpu_update() is called at various > places to update the CPU usage of each thread: > > static void > sched_pctcpu_update(struct td_sched *ts, int run) > { > int t = ticks; > > if (t - ts->ts_ltick >= SCHED_TICK_TARG) { > ts->ts_ticks = 0; > ts->ts_ftick = t - SCHED_TICK_TARG; > } else if (t - ts->ts_ftick >= SCHED_TICK_MAX) { > ts->ts_ticks = (ts->ts_ticks / (ts->ts_ltick - ts->ts_ftick)) * > (ts->ts_ltick - (t - SCHED_TICK_TARG)); > ts->ts_ftick = t - SCHED_TICK_TARG; > } > if (run) > ts->ts_ticks += (t - ts->ts_ltick) << SCHED_TICK_SHIFT; > ts->ts_ltick = t; > } > > The problem with it is that it only seems to work at the granularity > of 1 tick. My polling threads get woken up at each hardclock() > invocation and stop running before the next hardclock() invocation, so > ticks is (almost) never incremented while the polling thread is > running. This means that when sched_pctcpu_update is called when the > polling thread is going to sleep, run=1 but ts->ts_ltick == ticks, so > ts_ticks is incremented by 0. When the polling thread is woken up > again, ticks has been incremented in the meantime and > sched_pctcpu_update is called with run=0, so ts_ticks is not > incremented but ltick is set to ticks. The effect is that ts_ticks is > never incremented so CPU usage is always reported as 0. > > I think that you'll see the same effect with the softclock threads, too. That is obvious that it is impossible to measure pctcpu for hardclock - synchronized threads using hardclock as the only time source. Mentioned change made things neither more nor less broken then they already were. > I've experimented with reverting r232917 and instead moving the > sampling code from sched_tick() to sched_clock(), and that seems to > give me reasonably accurate results (for my workload, anyway). That approach will fix pctcpu accounting for thread synchronized to hardclock, but I worry can make worse for threads switching context around statclock. > The > other option would be to use a timer with a higher granularity than > ticks in sched_pctcpu_update(). That would be great it we had reliable and cheap timers on x86. Now ones that are fast (TSC) are unreliable, others that are reliable are too slow for this use. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 20:59:23 2012 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 69F06106566B for ; Wed, 18 Jul 2012 20:59:23 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8CEF8FC0C for ; Wed, 18 Jul 2012 20:59:22 +0000 (UTC) Received: by lbon10 with SMTP id n10so3323550lbo.13 for ; Wed, 18 Jul 2012 13:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+C1BZnVA60UzfNwAaOQD0g/8lwx+Od9OsDhzAasHq1U=; b=xieFe6WcEcV4htPhOh2RTTiRoL/zCK+gnzTjLYZvizIQvAV5rh1wHJCRdfPxZsLh6T qUZ24Yma7pUmlzZNYRRdnL6tBvMJ0UNgqGtSF3vUrpgrmh5lmWEgR9BBonN2s/nm73nh 3v3zqVHtV7qwV2NWbKfaTIHnuIpHGSkyjeu3lDJ0eDXuW1cyCNk/5ZvRDwCuyajKJDli jsAT5mHNKp4k+npH4dMIX6RUhJqvPF6XeyIU1q+3qJxhVeasjD6pEgtnInRLKahc498P fv4ROXHsr8Gjdx92GJgkiGywrrQyGEUi3wLwwjRBqTO2FHDbMDrBCDN8Mwrt5Pdk4nMX nRkw== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr5207868lab.8.1342645161462; Wed, 18 Jul 2012 13:59:21 -0700 (PDT) Sender: jamebus@gmail.com Received: by 10.112.78.9 with HTTP; Wed, 18 Jul 2012 13:59:21 -0700 (PDT) In-Reply-To: References: <4FFF4B95.9080105@delphij.net> Date: Wed, 18 Jul 2012 15:59:21 -0500 X-Google-Sender-Auth: Co0tNPTECX_uugS0eMqzSJvi9qo Message-ID: From: James To: Bill Crisp Content-Type: multipart/mixed; boundary=f46d04374547e88d5604c520efff Cc: freebsd-hackers@freebsd.org, Xin Li Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.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: Wed, 18 Jul 2012 20:59:23 -0000 --f46d04374547e88d5604c520efff Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 3:26 PM, Bill Crisp wrote: > > Unfortunately I tried to put the code from the patch in place but there > seems to be some missing functions in the header file and too many > arguments to a function and some other errors below: Hi Bill. Yes, the patch for >= FreeBSD 7 won't apply directly to 6. ksi and the refined SIGBUS traps don't exist yet. Here's how I fixed it at work. Using this on multiple releng_6* branches. HTH! -- James. --f46d04374547e88d5604c520efff Content-Type: application/octet-stream; name="CVE-2012-0217_releng_6.patch" Content-Disposition: attachment; filename="CVE-2012-0217_releng_6.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h4sw8opl0 SW5kZXg6IHNyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNyYy9zeXMv YW1kNjQvYW1kNjQvdHJhcC5jCShyZXZpc2lvbiA0NTY0KQorKysgc3JjL3N5cy9hbWQ2NC9hbWQ2 NC90cmFwLmMJKHJldmlzaW9uIDQ1NjUpCkBAIC04NDYsNiArODQ2LDE3IEBACiAJLyoKIAkgKiBU cmFjZWQgc3lzY2FsbC4KIAkgKi8KKworCS8qCisJICogSWYgdGhlIHVzZXItc3VwcGxpZWQgdmFs dWUgb2YgJXJpcCBpcyBub3QgYSBjYW5vbmljYWwKKwkgKiBhZGRyZXNzLCB0aGVuIHNvbWUgQ1BV cyB3aWxsIHRyaWdnZXIgYSByaW5nIDAgI0dQIGR1cmluZworCSAqIHRoZSBzeXNyZXQgaW5zdHJ1 Y3Rpb24uICBIb3dldmVyLCB0aGUgZmF1bHQgaGFuZGxlciB3b3VsZAorCSAqIGV4ZWN1dGUgd2l0 aCB0aGUgdXNlcidzICVncyBhbmQgJXJzcCBpbiByaW5nIDAgd2hpY2ggd291bGQKKwkgKiBub3Qg YmUgc2FmZS4gIEluc3RlYWQsIHByZWVtcHRpdmVseSBraWxsIHRoZSB0aHJlYWQgd2l0aCBhCisJ ICogU0lHQlVTLgorCSAqLworCWlmICh0ZC0+dGRfZnJhbWUtPnRmX3JpcCA+PSBWTV9NQVhVU0VS X0FERFJFU1MpCisJCXRyYXBzaWduYWwodGQsIFNJR0JVUywgVF9QUk9URkxUKTsKIAlpZiAob3Jp Z190Zl9yZmxhZ3MgJiBQU0xfVCkgewogCQlmcmFtZS50Zl9yZmxhZ3MgJj0gflBTTF9UOwogCQl0 cmFwc2lnbmFsKHRkLCBTSUdUUkFQLCAwKTsK --f46d04374547e88d5604c520efff-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 08:27:39 2012 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 E8954106566B for ; Thu, 19 Jul 2012 08:27:39 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 548428FC14 for ; Thu, 19 Jul 2012 08:27:39 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6J8RbCP007514; Thu, 19 Jul 2012 10:27:37 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6J8Rb6N007511; Thu, 19 Jul 2012 10:27:37 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 19 Jul 2012 10:27:37 +0200 (CEST) From: Wojciech Puchar To: Chris Rees In-Reply-To: Message-ID: References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 19 Jul 2012 10:27:38 +0200 (CEST) Cc: Dave Hayes , freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 19 Jul 2012 08:27:40 -0000 > > 1) XML output from some sysctl variables. It isn't just stupid. It's sad. > > 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it > allowed editing everytime and all worked. > > > > "Preventing people doing stupid things would prevent doing clever things". ^^^^^^^^^^^^^^^^^ > Bsdlabel was a monstrosity that required a calculator to hand to do anything useful. > > Gpart on the other hand is easily scriptable. off topic. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 08:33:22 2012 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 B63A91065674 for ; Thu, 19 Jul 2012 08:33:22 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 12CD28FC0C for ; Thu, 19 Jul 2012 08:33:21 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6J8XK2j007550; Thu, 19 Jul 2012 10:33:20 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6J8XKnp007547; Thu, 19 Jul 2012 10:33:20 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 19 Jul 2012 10:33:20 +0200 (CEST) From: Wojciech Puchar To: Dave Hayes In-Reply-To: <5007129E.6020701@jetcafe.org> Message-ID: References: <20120717183221.298430@gmx.com> <20120717153505.42633535@bhuda.mired.org> <5005D181.8080709@jetcafe.org> <5007129E.6020701@jetcafe.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 19 Jul 2012 10:33:20 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?) 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, 19 Jul 2012 08:33:22 -0000 > to me...man pages are -reference- material. They are not intended to be the > 'right way' to learn something, but instead as a quick reference guide. manual pages are intended to PROPERLY describe how program/function etc. operates. > Of course, I doubt anyone can make a case for the 'one true right way' to > learn FreeBSD. True. > I would never teach someone to read the man pages as a way to > familiarize themselves with...say...geom(8). (In fact, I'd love to find some why? > The notion of a 'new user' is unfortunately too wide of a category to target > documentation to. The problem of today is "persistent new user". "New user since first time touched computer". > A secretary who's never seen anything but windows, a 5 year > old child, and a fresh PhD in computer science might all fit this category. > Each of these people requires different levels of teaching. Secretary should not be FreeBSD admin, while of course can be FreeBSD user. Unix makes clear distinction between user and admin. Modern computing style blurs it. > Everytime I see these discussions my mind flashes to a web based wiki where > everyone writes helpful information (like the Emacs Wiki) on various topics > and it's fairly well indexed so you can see related ideas. Does something > like this exist for FreeBSD? No idea. What i HATE in very modern software is wiki-style "documentation". >> 4) Adding features that are not really finished and in working state. >> gjournal is an example, background fsck is another (everyone actually >> ends in background_fsck=NO) > > Well you have me there, I thought background fsck worked...I just left it on > because it's set like that in /etc/defaults/rc.conf. snapshots do crash on big filesystems. And after background fsck often you will find more errors by foreground fsck. Anyway it is not a problem really. Just don't make bulky virtual volumes of 100 disks, as it is not just slow to fsck but dangerous. if your server works for people that cannot stand half an hour of downtime then change to 0 all /etc/fstab positions except of most important, then after a crash do fsck after worktime. with softupdates it is generally safe to run filesystem without fsck for some time. > >> Of course in the same time where are hundreds of good things done, and >> we all know it. But if people won't understand a problem NOW and fight >> it, it will become worse. > > If everyone is busy fighting evil, who is left to create the good? :) First "good" must be needed. Now "good" is defined by democratic means buy herd of "persistent newbies". Doing nothing is actually better than create new "goods" like that. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 09:14:47 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5A21B106564A; Thu, 19 Jul 2012 09:14:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6ECF214DDF8; Thu, 19 Jul 2012 09:14:43 +0000 (UTC) Message-ID: <5007D002.7000805@FreeBSD.org> Date: Thu, 19 Jul 2012 02:14:42 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: hselasky@FreeBSD.org X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 09:14:47 -0000 The xhci code in 8-stable works, but it's not mentioned in the NOTES files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is hooked up in sys/modules/usb/Makefile, and that's how I've been using it so far. Is it not possible to compile this code into the kernel? Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 09:22:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D17D81065672; Thu, 19 Jul 2012 09:22:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 343A18FC0C; Thu, 19 Jul 2012 09:22:38 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [84.49.175.101] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 297822190; Thu, 19 Jul 2012 11:17:27 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 19 Jul 2012 11:17:42 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <5007D002.7000805@FreeBSD.org> In-Reply-To: <5007D002.7000805@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207191117.42833.hselasky@c2i.net> Cc: Doug Barton Subject: Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 09:22:38 -0000 On Thursday 19 July 2012 11:14:42 Doug Barton wrote: > The xhci code in 8-stable works, but it's not mentioned in the NOTES > files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is > hooked up in sys/modules/usb/Makefile, and that's how I've been using it > so far. Is it not possible to compile this code into the kernel? > > Doug Yes, you can compile xhci into the kernel using "device xhci". Not sure who's responsible for updating NOTES. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 09:38:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 0F854106564A for ; Thu, 19 Jul 2012 09:38:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 69897151FFF; Thu, 19 Jul 2012 09:38:11 +0000 (UTC) Message-ID: <5007D583.5000809@FreeBSD.org> Date: Thu, 19 Jul 2012 02:38:11 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <5007D002.7000805@FreeBSD.org> <201207191117.42833.hselasky@c2i.net> In-Reply-To: <201207191117.42833.hselasky@c2i.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 09:38:12 -0000 On 07/19/2012 02:17, Hans Petter Selasky wrote: > On Thursday 19 July 2012 11:14:42 Doug Barton wrote: >> The xhci code in 8-stable works, but it's not mentioned in the NOTES >> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is >> hooked up in sys/modules/usb/Makefile, and that's how I've been using it >> so far. Is it not possible to compile this code into the kernel? >> >> Doug > > Yes, you can compile xhci into the kernel using "device xhci". Not sure who's > responsible for updating NOTES. That would be you. :) (Since AFAICS you added the code.) It should almost certainly also be in the GENERIC files for the systems to which it applies. In HEAD and stable/9 it's in sys/conf/NOTES, and {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8. Not sure if the code works on stable/7 or not, but we're going to do another release in stable/8 so it should be updated there for sure. Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 10:29:44 2012 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 9DDAA106567C; Thu, 19 Jul 2012 10:29:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id ED81F8FC20; Thu, 19 Jul 2012 10:29:43 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [84.49.175.101] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 299911146; Thu, 19 Jul 2012 12:29:36 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 19 Jul 2012 12:29:52 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <5007D002.7000805@FreeBSD.org> <201207191117.42833.hselasky@c2i.net> <5007D583.5000809@FreeBSD.org> In-Reply-To: <5007D583.5000809@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207191229.52222.hselasky@c2i.net> Cc: Doug Barton Subject: Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 10:29:44 -0000 On Thursday 19 July 2012 11:38:11 Doug Barton wrote: > On 07/19/2012 02:17, Hans Petter Selasky wrote: > > On Thursday 19 July 2012 11:14:42 Doug Barton wrote: > >> The xhci code in 8-stable works, but it's not mentioned in the NOTES > >> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is > >> hooked up in sys/modules/usb/Makefile, and that's how I've been using it > >> so far. Is it not possible to compile this code into the kernel? > >> > >> Doug > > > > Yes, you can compile xhci into the kernel using "device xhci". Not sure > > who's responsible for updating NOTES. > > That would be you. :) (Since AFAICS you added the code.) It should > almost certainly also be in the GENERIC files for the systems to which > it applies. > > In HEAD and stable/9 it's in sys/conf/NOTES, and > {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8. > Not sure if the code works on stable/7 or not, but we're going to do > another release in stable/8 so it should be updated there for sure. I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit. http://svn.freebsd.org/changeset/base/238616 --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 10:34:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B6A15106566B for ; Thu, 19 Jul 2012 10:34:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 214CD14EBCD; Thu, 19 Jul 2012 10:34:35 +0000 (UTC) Message-ID: <5007E2BA.3010300@FreeBSD.org> Date: Thu, 19 Jul 2012 03:34:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <5007D002.7000805@FreeBSD.org> <201207191117.42833.hselasky@c2i.net> <5007D583.5000809@FreeBSD.org> <201207191229.52222.hselasky@c2i.net> In-Reply-To: <201207191229.52222.hselasky@c2i.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 10:34:35 -0000 On 07/19/2012 03:29, Hans Petter Selasky wrote: > On Thursday 19 July 2012 11:38:11 Doug Barton wrote: >> On 07/19/2012 02:17, Hans Petter Selasky wrote: >>> On Thursday 19 July 2012 11:14:42 Doug Barton wrote: >>>> The xhci code in 8-stable works, but it's not mentioned in the NOTES >>>> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is >>>> hooked up in sys/modules/usb/Makefile, and that's how I've been using it >>>> so far. Is it not possible to compile this code into the kernel? >>>> >>>> Doug >>> >>> Yes, you can compile xhci into the kernel using "device xhci". Not sure >>> who's responsible for updating NOTES. >> >> That would be you. :) (Since AFAICS you added the code.) It should >> almost certainly also be in the GENERIC files for the systems to which >> it applies. >> >> In HEAD and stable/9 it's in sys/conf/NOTES, and >> {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8. >> Not sure if the code works on stable/7 or not, but we're going to do >> another release in stable/8 so it should be updated there for sure. > > I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit. > > http://svn.freebsd.org/changeset/base/238616 Thanks! What are your concerns about adding it to GENERIC? -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 10:38:32 2012 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 CDED4106566B; Thu, 19 Jul 2012 10:38:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFFF8FC08; Thu, 19 Jul 2012 10:38:31 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [84.49.175.101] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 301768233; Thu, 19 Jul 2012 12:38:24 +0200 From: Hans Petter Selasky To: Doug Barton Date: Thu, 19 Jul 2012 12:38:39 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <5007D002.7000805@FreeBSD.org> <201207191229.52222.hselasky@c2i.net> <5007E2BA.3010300@FreeBSD.org> In-Reply-To: <5007E2BA.3010300@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207191238.39747.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable? 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, 19 Jul 2012 10:38:32 -0000 On Thursday 19 July 2012 12:34:34 Doug Barton wrote: > On 07/19/2012 03:29, Hans Petter Selasky wrote: > > On Thursday 19 July 2012 11:38:11 Doug Barton wrote: > >> On 07/19/2012 02:17, Hans Petter Selasky wrote: > >>> On Thursday 19 July 2012 11:14:42 Doug Barton wrote: > >>>> The xhci code in 8-stable works, but it's not mentioned in the NOTES > >>>> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is > >>>> hooked up in sys/modules/usb/Makefile, and that's how I've been using > >>>> it so far. Is it not possible to compile this code into the kernel? > >>>> > >>>> Doug > >>> > >>> Yes, you can compile xhci into the kernel using "device xhci". Not sure > >>> who's responsible for updating NOTES. > >> > >> That would be you. :) (Since AFAICS you added the code.) It should > >> almost certainly also be in the GENERIC files for the systems to which > >> it applies. > >> > >> In HEAD and stable/9 it's in sys/conf/NOTES, and > >> {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8. > >> Not sure if the code works on stable/7 or not, but we're going to do > >> another release in stable/8 so it should be updated there for sure. > > > > I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit. > > > > http://svn.freebsd.org/changeset/base/238616 > > Thanks! What are your concerns about adding it to GENERIC? Hi, I don't see any problems at the present. I think all issues have been ironed out including the 32/64 byte context sizes. From what I'm aware the XHCI driver in 8-stable should be the same like in 9- and 10- except from a recent patch done by mav @. This patch should not make a big difference, except for INTEL patherpoint devices. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 15:08:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6901106564A; Thu, 19 Jul 2012 15:08:20 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 890268FC14; Thu, 19 Jul 2012 15:08:20 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Thu, 19 Jul 2012 09:56:49 -0500 From: Paul Albrecht To: Davide Italiano In-Reply-To: References: <1342036332.8313.8.camel@albrecht-desktop> <201207121026.37849.jhb@freebsd.org> <201207121125.01228.jhb@freebsd.org> Content-Type: text/plain Date: Thu, 19 Jul 2012 10:06:07 -0500 Message-ID: <1342710367.6938.6.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Paul Albrecht , "freebsd-hackers@freebsd.org" Subject: Re: kqueue periodic timer confusion 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, 19 Jul 2012 15:08:20 -0000 On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote: > On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote: > > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: > >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > >> >> > > > Hi, > >> >> > > > > >> >> > > > Sorry about this repost but I'm confused about the responses I received > >> >> > > > in my last post so I'm looking for some clarification. > >> >> > > > > >> >> > > > Specifically, I though I could use the kqueue timer as essentially a > >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that > >> >> > > > the accuracy of the kqueue timer is much less than what I need for my > >> >> > > > application. > >> >> > > > > >> >> > > > So my confusion at this point is whether this is consider to be a bug or > >> >> > > > "feature"? > >> >> > > > > >> >> > > > Here's some test code if you want to verify the problem: > >> >> > > > > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > > >> >> > > > int > >> >> > > > main(void) > >> >> > > > { > >> >> > > > int i,msec; > >> >> > > > int kq,nev; > >> >> > > > struct kevent inqueue; > >> >> > > > struct kevent outqueue; > >> >> > > > struct timeval start,end; > >> >> > > > > >> >> > > > if ((kq = kqueue()) == -1) { > >> >> > > > fprintf(stderr, "kqueue error!? errno = %s", > >> >> > strerror(errno)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } > >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > >> >> > > > > >> >> > > > gettimeofday(&start, 0); > >> >> > > > for (i = 0; i < 50; i++) { > >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > >> >> > -1) { > >> >> > > > fprintf(stderr, "kevent error!? errno = %s", > >> >> > strerror(errno)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } else if (outqueue.flags & EV_ERROR) { > >> >> > > > fprintf(stderr, "EV_ERROR: %s\n", > >> >> > strerror(outqueue.data)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } > >> >> > > > } > >> >> > > > gettimeofday(&end, 0); > >> >> > > > > >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000); > >> >> > > > > >> >> > > > printf("msec = %d\n", msec); > >> >> > > > > >> >> > > > close(kq); > >> >> > > > return EXIT_SUCCESS; > >> >> > > > } > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > What you are seeing is "just the way FreeBSD currently works." > >> >> > > > >> >> > > Sleeping (in most all of its various forms, and I've just looked at the > >> >> > > kevent code to verify this is true there) is handled by converting the > >> >> > > amount of time to sleep (usually specified in a timeval or timespec > >> >> > > struct) to a count of timer ticks, using an internal routine called > >> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > >> >> > > account for the current tick. Whether that's a good idea or not (it > >> >> > > probably was once, and probably not anymore) it's how things currently > >> >> > > work, and could explain the fairly consistant +1ms you're seeing. > >> >> > > >> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > >> >> > installs a periodic callout that executes KNOTE() and then resets itself (via > >> >> > callout_reset()) each time it runs. This should generally be closer to > >> >> > regulary spaced intervals than something that does: > >> >> > > >> >> > >> >> In what way is it irrelevant? That is, what did I miss? It appears to > >> >> me that the next callout is scheduled by calling timertoticks() passing > >> >> a count of milliseconds, that count is converted to a struct timeval and > >> >> passed to tvtohz() which is where the +1 adjustment happens. If you ask > >> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > >> >> There is some time, likely a small number of microseconds, that you've > >> >> consumed of the current tick, and that's what the +1 in tvtohz() is > >> >> supposed to account for according to the comments. > >> >> > >> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > >> >> and then adds one tick on top of that. That seems not quite right to > >> >> me, except that it is a way to g'tee that you don't return early, and > >> >> that is the one promise made by sleep routines on any OS; those magical > >> >> "at least" words always appear in the docs. > >> >> > >> >> Actually what I'm missing (that I know of) is how the scheduler works. > >> >> Maybe the +1 adjustment to account for the fraction of the current tick > >> >> you've already consumed is the right thing to do, even when that > >> >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler > >> >> behavior that I know nothing about. > >> > > >> > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > >> > case. That is, the +1 makes sense when you are computing a one-time delta > >> > for things like nanosleep(). It is incorrect when computing a periodic > >> > delta such as for computing the interval for an itimer (setitimer) or > >> > EVFILT_TIMER(). > >> > > >> > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > >> > > >> > sys/kern/kern_time.c: > >> > > >> > /* > >> > * Real interval timer expired: > >> > * send process whose timer expired an alarm signal. > >> > * If time is not set up to reload, then just return. > >> > * Else compute next time timer should go off which is > current time. > >> > * This is where delay in processing this timeout causes multiple > >> > * SIGALRM calls to be compressed into one. > >> > * tvtohz() always adds 1 to allow for the time until the next clock > >> > * interrupt being strictly less than 1 clock tick, but we don't want > >> > * that here since we want to appear to be in sync with the clock > >> > * interrupt even when we're delayed. > >> > */ > >> > void > >> > realitexpire(void *arg) > >> > { > >> > struct proc *p; > >> > struct timeval ctv, ntv; > >> > > >> > p = (struct proc *)arg; > >> > PROC_LOCK(p); > >> > kern_psignal(p, SIGALRM); > >> > if (!timevalisset(&p->p_realtimer.it_interval)) { > >> > timevalclear(&p->p_realtimer.it_value); > >> > if (p->p_flag & P_WEXIT) > >> > wakeup(&p->p_itcallout); > >> > PROC_UNLOCK(p); > >> > return; > >> > } > >> > for (;;) { > >> > timevaladd(&p->p_realtimer.it_value, > >> > &p->p_realtimer.it_interval); > >> > getmicrouptime(&ctv); > >> > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > >> > ntv = p->p_realtimer.it_value; > >> > timevalsub(&ntv, &ctv); > >> > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > >> > realitexpire, p); > >> > PROC_UNLOCK(p); > >> > return; > >> > } > >> > } > >> > /*NOTREACHED*/ > >> > } > >> > > >> > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > >> > seitimer() above: > >> > > >> > Index: kern_event.c > >> > =================================================================== > >> > --- kern_event.c (revision 238365) > >> > +++ kern_event.c (working copy) > >> > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > >> > > >> > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > >> > calloutp = (struct callout *)kn->kn_hook; > >> > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > >> > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > >> > filt_timerexpire, kn); > >> > } > >> > } > >> > > >> > -- > >> > John Baldwin > >> > _______________________________________________ > >> > 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" > >> > >> John, > >> I don't think it's good to decrease by a unit the 'ticks' you pass to > >> callout_reset_* KPI. > >> If this have to be fixed it should be fixed at the callout level and > >> not at the consumer level. In other words, subsystems that makes use > >> of callout_reset_* should not deal with the inherent limitations of > >> callout precision, as it is right now. > > > > Given that you are reworking callout already, it would seem a bit odd > > to rework callout a separate time just to fix this bug. A simple fix > > like this (which follows the same pattern we already use for setitimer()) > > is something we can easily merge back to 8 and 9. Reworking callout in > > a different way than you are already doing, OTOH, is not something we can > > merge trivially. > > > > -- > > John Baldwin > > I understand what you mean. Indeed I hadn't thought about the > difficulties of merging that work back. Only a thing: if I'd were you > before committing I'd add a comment explaining the reasons of the > negative correction in the timeout value passed. > ... and you're going to test the kqueue perioic timer after you make your changes to make sure there aren't any regressions? Right? The reason I'm asking is because darwin's bsd subsystem uses the callout framework for its kqueue implementation and the periodic timer is of course broken. > Davide -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 15:11:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB5BE1065673; Thu, 19 Jul 2012 15:11:10 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A47638FC17; Thu, 19 Jul 2012 15:11:10 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so4906604pbb.13 for ; Thu, 19 Jul 2012 08:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WyxAZFMakUHZ2JWOdyRlw0AFYyntSg0zQ+Pd2SyClO0=; b=su4Df9GLVIxRZ9ns6GU+Ld+EqZsqN40bUAQ6I/EXxsDRKlD2/KdPjkPNCdsJ8U+0+P 7DftZo0YTW7u85/CcCxMFlEbRc4gkfuWDsLugAE0P9HkFAervBGVBKsYJHG4YgOSsutm V0KFwFCwFq7wYL1SRaNhHSaBiY0JHplZL9/DVZcKh7WbQujRSXWXKZkpqpu2XvewutF2 lVzb+5LZ7kzS/Lyt9Rrt1VjtrVK5+BZtBE0vWKD34sr5Bml2ZPDb4MIhM7eoF/swYNQ0 RetetP7o4AKK6lH+oeClrYtWpHQFPsCYLevj3V5E4K+JEmXK2s5muZ+SIwStSZiBp18P OuIg== MIME-Version: 1.0 Received: by 10.68.203.66 with SMTP id ko2mr6070126pbc.84.1342710670133; Thu, 19 Jul 2012 08:11:10 -0700 (PDT) Received: by 10.66.82.201 with HTTP; Thu, 19 Jul 2012 08:11:10 -0700 (PDT) In-Reply-To: <1342710367.6938.6.camel@albrecht-desktop> References: <1342036332.8313.8.camel@albrecht-desktop> <201207121026.37849.jhb@freebsd.org> <201207121125.01228.jhb@freebsd.org> <1342710367.6938.6.camel@albrecht-desktop> Date: Thu, 19 Jul 2012 17:11:10 +0200 Message-ID: From: Davide Italiano To: Paul Albrecht Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Paul Albrecht , "freebsd-hackers@freebsd.org" Subject: Re: kqueue periodic timer confusion 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, 19 Jul 2012 15:11:11 -0000 On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote: > On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote: >> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote: >> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: >> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: >> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: >> >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: >> >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: >> >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: >> >> >> > > > Hi, >> >> >> > > > >> >> >> > > > Sorry about this repost but I'm confused about the responses I received >> >> >> > > > in my last post so I'm looking for some clarification. >> >> >> > > > >> >> >> > > > Specifically, I though I could use the kqueue timer as essentially a >> >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that >> >> >> > > > the accuracy of the kqueue timer is much less than what I need for my >> >> >> > > > application. >> >> >> > > > >> >> >> > > > So my confusion at this point is whether this is consider to be a bug or >> >> >> > > > "feature"? >> >> >> > > > >> >> >> > > > Here's some test code if you want to verify the problem: >> >> >> > > > >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > #include >> >> >> > > > >> >> >> > > > int >> >> >> > > > main(void) >> >> >> > > > { >> >> >> > > > int i,msec; >> >> >> > > > int kq,nev; >> >> >> > > > struct kevent inqueue; >> >> >> > > > struct kevent outqueue; >> >> >> > > > struct timeval start,end; >> >> >> > > > >> >> >> > > > if ((kq = kqueue()) == -1) { >> >> >> > > > fprintf(stderr, "kqueue error!? errno = %s", >> >> >> > strerror(errno)); >> >> >> > > > exit(EXIT_FAILURE); >> >> >> > > > } >> >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); >> >> >> > > > >> >> >> > > > gettimeofday(&start, 0); >> >> >> > > > for (i = 0; i < 50; i++) { >> >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == >> >> >> > -1) { >> >> >> > > > fprintf(stderr, "kevent error!? errno = %s", >> >> >> > strerror(errno)); >> >> >> > > > exit(EXIT_FAILURE); >> >> >> > > > } else if (outqueue.flags & EV_ERROR) { >> >> >> > > > fprintf(stderr, "EV_ERROR: %s\n", >> >> >> > strerror(outqueue.data)); >> >> >> > > > exit(EXIT_FAILURE); >> >> >> > > > } >> >> >> > > > } >> >> >> > > > gettimeofday(&end, 0); >> >> >> > > > >> >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + >> >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000); >> >> >> > > > >> >> >> > > > printf("msec = %d\n", msec); >> >> >> > > > >> >> >> > > > close(kq); >> >> >> > > > return EXIT_SUCCESS; >> >> >> > > > } >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > > What you are seeing is "just the way FreeBSD currently works." >> >> >> > > >> >> >> > > Sleeping (in most all of its various forms, and I've just looked at the >> >> >> > > kevent code to verify this is true there) is handled by converting the >> >> >> > > amount of time to sleep (usually specified in a timeval or timespec >> >> >> > > struct) to a count of timer ticks, using an internal routine called >> >> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to >> >> >> > > account for the current tick. Whether that's a good idea or not (it >> >> >> > > probably was once, and probably not anymore) it's how things currently >> >> >> > > work, and could explain the fairly consistant +1ms you're seeing. >> >> >> > >> >> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER >> >> >> > installs a periodic callout that executes KNOTE() and then resets itself (via >> >> >> > callout_reset()) each time it runs. This should generally be closer to >> >> >> > regulary spaced intervals than something that does: >> >> >> > >> >> >> >> >> >> In what way is it irrelevant? That is, what did I miss? It appears to >> >> >> me that the next callout is scheduled by calling timertoticks() passing >> >> >> a count of milliseconds, that count is converted to a struct timeval and >> >> >> passed to tvtohz() which is where the +1 adjustment happens. If you ask >> >> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. >> >> >> There is some time, likely a small number of microseconds, that you've >> >> >> consumed of the current tick, and that's what the +1 in tvtohz() is >> >> >> supposed to account for according to the comments. >> >> >> >> >> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick >> >> >> and then adds one tick on top of that. That seems not quite right to >> >> >> me, except that it is a way to g'tee that you don't return early, and >> >> >> that is the one promise made by sleep routines on any OS; those magical >> >> >> "at least" words always appear in the docs. >> >> >> >> >> >> Actually what I'm missing (that I know of) is how the scheduler works. >> >> >> Maybe the +1 adjustment to account for the fraction of the current tick >> >> >> you've already consumed is the right thing to do, even when that >> >> >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler >> >> >> behavior that I know nothing about. >> >> > >> >> > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this >> >> > case. That is, the +1 makes sense when you are computing a one-time delta >> >> > for things like nanosleep(). It is incorrect when computing a periodic >> >> > delta such as for computing the interval for an itimer (setitimer) or >> >> > EVFILT_TIMER(). >> >> > >> >> > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: >> >> > >> >> > sys/kern/kern_time.c: >> >> > >> >> > /* >> >> > * Real interval timer expired: >> >> > * send process whose timer expired an alarm signal. >> >> > * If time is not set up to reload, then just return. >> >> > * Else compute next time timer should go off which is > current time. >> >> > * This is where delay in processing this timeout causes multiple >> >> > * SIGALRM calls to be compressed into one. >> >> > * tvtohz() always adds 1 to allow for the time until the next clock >> >> > * interrupt being strictly less than 1 clock tick, but we don't want >> >> > * that here since we want to appear to be in sync with the clock >> >> > * interrupt even when we're delayed. >> >> > */ >> >> > void >> >> > realitexpire(void *arg) >> >> > { >> >> > struct proc *p; >> >> > struct timeval ctv, ntv; >> >> > >> >> > p = (struct proc *)arg; >> >> > PROC_LOCK(p); >> >> > kern_psignal(p, SIGALRM); >> >> > if (!timevalisset(&p->p_realtimer.it_interval)) { >> >> > timevalclear(&p->p_realtimer.it_value); >> >> > if (p->p_flag & P_WEXIT) >> >> > wakeup(&p->p_itcallout); >> >> > PROC_UNLOCK(p); >> >> > return; >> >> > } >> >> > for (;;) { >> >> > timevaladd(&p->p_realtimer.it_value, >> >> > &p->p_realtimer.it_interval); >> >> > getmicrouptime(&ctv); >> >> > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { >> >> > ntv = p->p_realtimer.it_value; >> >> > timevalsub(&ntv, &ctv); >> >> > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, >> >> > realitexpire, p); >> >> > PROC_UNLOCK(p); >> >> > return; >> >> > } >> >> > } >> >> > /*NOTREACHED*/ >> >> > } >> >> > >> >> > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as >> >> > seitimer() above: >> >> > >> >> > Index: kern_event.c >> >> > =================================================================== >> >> > --- kern_event.c (revision 238365) >> >> > +++ kern_event.c (working copy) >> >> > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) >> >> > >> >> > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { >> >> > calloutp = (struct callout *)kn->kn_hook; >> >> > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), >> >> > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, >> >> > filt_timerexpire, kn); >> >> > } >> >> > } >> >> > >> >> > -- >> >> > John Baldwin >> >> > _______________________________________________ >> >> > 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" >> >> >> >> John, >> >> I don't think it's good to decrease by a unit the 'ticks' you pass to >> >> callout_reset_* KPI. >> >> If this have to be fixed it should be fixed at the callout level and >> >> not at the consumer level. In other words, subsystems that makes use >> >> of callout_reset_* should not deal with the inherent limitations of >> >> callout precision, as it is right now. >> > >> > Given that you are reworking callout already, it would seem a bit odd >> > to rework callout a separate time just to fix this bug. A simple fix >> > like this (which follows the same pattern we already use for setitimer()) >> > is something we can easily merge back to 8 and 9. Reworking callout in >> > a different way than you are already doing, OTOH, is not something we can >> > merge trivially. >> > >> > -- >> > John Baldwin >> >> I understand what you mean. Indeed I hadn't thought about the >> difficulties of merging that work back. Only a thing: if I'd were you >> before committing I'd add a comment explaining the reasons of the >> negative correction in the timeout value passed. >> > > ... and you're going to test the kqueue perioic timer after you make > your changes to make sure there aren't any regressions? Right? > Yes, this is the idea. > The reason I'm asking is because darwin's bsd subsystem uses the callout > framework for its kqueue implementation and the periodic timer is of > course broken. > >> Davide > -- > Paul Albrecht > Davide From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 18:29:55 2012 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 56671106564A for ; Thu, 19 Jul 2012 18:29:55 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 347738FC18 for ; Thu, 19 Jul 2012 18:29:55 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 163401B4092 for ; Thu, 19 Jul 2012 18:29:48 +0000 (UTC) Message-ID: <50085193.6030203@gentoo.org> Date: Thu, 19 Jul 2012 14:27:31 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: "hackers@FreeBSD.org" X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC7E672086F469F16601A803" Cc: Subject: Awful FreeBSD 9 block IO performance in KVM 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, 19 Jul 2012 18:29:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC7E672086F469F16601A803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Everyone, FreeBSD 9 has awful block IO performance in KVM. I have experienced it and others have experienced it. Someone posted slides to slideshare with benchmarks documenting it: http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm Slides 13 and 20 are particular eye openers. Does anyone know what is wro= ng? Yours truly, Richard Yao --------------enigCC7E672086F469F16601A803 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCFGYAAoJECDuEZm+6ExkDSYP/2fZIyM8e1fO4vZWnJTbJd77 HomcwQ3BRHz4z87gYTP6Xbby6x97Xsp3x/aPlEd2YE6g6gZuZxUdgvA6Ufa9DaID 3Z8u7BLaF4r4TOUDIsgQ9FhHcYTR23fMHMIYuXEQspjhcwiKWZpzkEYak2dJGi39 M2ig+hXiYv2jnSMD351oL5B0oeJ6WE2l3r0iQjxR78jXz5r4LtHSmYFDHhRFmQ6D HVY7xlpdW2Zb/yeKY5EcyAQTZtSWWjMuLH9PVq9+miyU34x5Oel1B8EMbvjUlDGx fDsALGIYvlgtE7YvVgQaG0f7+VpKiJ30Mp8DfRJ4JLEVNFiG72boLJSwfLXUhZ10 1QsuIRAU11FR6H839BXUJIyFSkMGKtdyENACrajO6A9tRvA4IxG4lEyAti3mxCB9 qGMZztwJPfbyy/yWOUnFrXHFQQEhjY7N09Ic968paKtsU0mIb5BjIaR0JRSy3YEI MTPX9aA62+IKEPpMiyo/2qcmFbGwVAuaBDsyvefecXjMlCmtljfque3eBcNw1cDj 5bV2OOl13sZxCdTqzcC+A7yI9LFvpHc0QDxZkMiGZUogFGvWt9cFLRbFmg4dfs1u pq954Vh7D+gmtDMXFaYXMzjdrnBq4dXF4Lb0p3HLsji08BPyyyeYzJKjlEQFJqXe NAnBX5DRaGGARUvU/gS+ =4j/B -----END PGP SIGNATURE----- --------------enigCC7E672086F469F16601A803-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 20:33:30 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29899106564A for ; Thu, 19 Jul 2012 20:33:30 +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 5056B8FC16 for ; Thu, 19 Jul 2012 20:33:29 +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 XAA18250 for ; Thu, 19 Jul 2012 23:33:27 +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 1SrxPb-000ADs-Dd for freebsd-hackers@freebsd.org; Thu, 19 Jul 2012 23:33:27 +0300 Message-ID: <50086F15.2070106@FreeBSD.org> Date: Thu, 19 Jul 2012 23:33:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <1342036332.8313.8.camel@albrecht-desktop> <201207121026.37849.jhb@freebsd.org> <201207121125.01228.jhb@freebsd.org> <1342710367.6938.6.camel@albrecht-desktop> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: kqueue periodic timer confusion 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, 19 Jul 2012 20:33:30 -0000 on 19/07/2012 18:11 Davide Italiano said the following: > On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote: >> On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote: >>> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote: >>>> On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: >>>>> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: >>>>>> On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: >>>>>>> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: >>>>>>>> On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: >>>>>>>>> On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Sorry about this repost but I'm confused about the responses I received >>>>>>>>>> in my last post so I'm looking for some clarification. >>>>>>>>>> >>>>>>>>>> Specifically, I though I could use the kqueue timer as essentially a >>>>>>>>>> "drop in" replacement for linuxfd_create/read, but was surprised that >>>>>>>>>> the accuracy of the kqueue timer is much less than what I need for my >>>>>>>>>> application. >>>>>>>>>> >>>>>>>>>> So my confusion at this point is whether this is consider to be a bug or >>>>>>>>>> "feature"? >>>>>>>>>> >>>>>>>>>> Here's some test code if you want to verify the problem: >>>>>>>>>> >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> >>>>>>>>>> int >>>>>>>>>> main(void) >>>>>>>>>> { >>>>>>>>>> int i,msec; >>>>>>>>>> int kq,nev; >>>>>>>>>> struct kevent inqueue; >>>>>>>>>> struct kevent outqueue; >>>>>>>>>> struct timeval start,end; >>>>>>>>>> >>>>>>>>>> if ((kq = kqueue()) == -1) { >>>>>>>>>> fprintf(stderr, "kqueue error!? errno = %s", >>>>>>>> strerror(errno)); >>>>>>>>>> exit(EXIT_FAILURE); >>>>>>>>>> } >>>>>>>>>> EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); >>>>>>>>>> >>>>>>>>>> gettimeofday(&start, 0); >>>>>>>>>> for (i = 0; i < 50; i++) { >>>>>>>>>> if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == >>>>>>>> -1) { >>>>>>>>>> fprintf(stderr, "kevent error!? errno = %s", >>>>>>>> strerror(errno)); >>>>>>>>>> exit(EXIT_FAILURE); >>>>>>>>>> } else if (outqueue.flags & EV_ERROR) { >>>>>>>>>> fprintf(stderr, "EV_ERROR: %s\n", >>>>>>>> strerror(outqueue.data)); >>>>>>>>>> exit(EXIT_FAILURE); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> gettimeofday(&end, 0); >>>>>>>>>> >>>>>>>>>> msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + >>>>>>>> end.tv_usec - start.tv_usec) / 1000) - 1000); >>>>>>>>>> >>>>>>>>>> printf("msec = %d\n", msec); >>>>>>>>>> >>>>>>>>>> close(kq); >>>>>>>>>> return EXIT_SUCCESS; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> What you are seeing is "just the way FreeBSD currently works." >>>>>>>>> >>>>>>>>> Sleeping (in most all of its various forms, and I've just looked at the >>>>>>>>> kevent code to verify this is true there) is handled by converting the >>>>>>>>> amount of time to sleep (usually specified in a timeval or timespec >>>>>>>>> struct) to a count of timer ticks, using an internal routine called >>>>>>>>> tvtohz() in kern/kern_time.c. That routine rounds up by one tick to >>>>>>>>> account for the current tick. Whether that's a good idea or not (it >>>>>>>>> probably was once, and probably not anymore) it's how things currently >>>>>>>>> work, and could explain the fairly consistant +1ms you're seeing. >>>>>>>> >>>>>>>> This is all true, but mostly irrelevant for his case. EVFILT_TIMER >>>>>>>> installs a periodic callout that executes KNOTE() and then resets itself (via >>>>>>>> callout_reset()) each time it runs. This should generally be closer to >>>>>>>> regulary spaced intervals than something that does: >>>>>>>> >>>>>>> >>>>>>> In what way is it irrelevant? That is, what did I miss? It appears to >>>>>>> me that the next callout is scheduled by calling timertoticks() passing >>>>>>> a count of milliseconds, that count is converted to a struct timeval and >>>>>>> passed to tvtohz() which is where the +1 adjustment happens. If you ask >>>>>>> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. >>>>>>> There is some time, likely a small number of microseconds, that you've >>>>>>> consumed of the current tick, and that's what the +1 in tvtohz() is >>>>>>> supposed to account for according to the comments. >>>>>>> >>>>>>> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick >>>>>>> and then adds one tick on top of that. That seems not quite right to >>>>>>> me, except that it is a way to g'tee that you don't return early, and >>>>>>> that is the one promise made by sleep routines on any OS; those magical >>>>>>> "at least" words always appear in the docs. >>>>>>> >>>>>>> Actually what I'm missing (that I know of) is how the scheduler works. >>>>>>> Maybe the +1 adjustment to account for the fraction of the current tick >>>>>>> you've already consumed is the right thing to do, even when that >>>>>>> fraction is 1uS or less of a 1mS tick. That would depend on scheduler >>>>>>> behavior that I know nothing about. >>>>>> >>>>>> Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this >>>>>> case. That is, the +1 makes sense when you are computing a one-time delta >>>>>> for things like nanosleep(). It is incorrect when computing a periodic >>>>>> delta such as for computing the interval for an itimer (setitimer) or >>>>>> EVFILT_TIMER(). >>>>>> >>>>>> Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: >>>>>> >>>>>> sys/kern/kern_time.c: >>>>>> >>>>>> /* >>>>>> * Real interval timer expired: >>>>>> * send process whose timer expired an alarm signal. >>>>>> * If time is not set up to reload, then just return. >>>>>> * Else compute next time timer should go off which is > current time. >>>>>> * This is where delay in processing this timeout causes multiple >>>>>> * SIGALRM calls to be compressed into one. >>>>>> * tvtohz() always adds 1 to allow for the time until the next clock >>>>>> * interrupt being strictly less than 1 clock tick, but we don't want >>>>>> * that here since we want to appear to be in sync with the clock >>>>>> * interrupt even when we're delayed. >>>>>> */ >>>>>> void >>>>>> realitexpire(void *arg) >>>>>> { >>>>>> struct proc *p; >>>>>> struct timeval ctv, ntv; >>>>>> >>>>>> p = (struct proc *)arg; >>>>>> PROC_LOCK(p); >>>>>> kern_psignal(p, SIGALRM); >>>>>> if (!timevalisset(&p->p_realtimer.it_interval)) { >>>>>> timevalclear(&p->p_realtimer.it_value); >>>>>> if (p->p_flag & P_WEXIT) >>>>>> wakeup(&p->p_itcallout); >>>>>> PROC_UNLOCK(p); >>>>>> return; >>>>>> } >>>>>> for (;;) { >>>>>> timevaladd(&p->p_realtimer.it_value, >>>>>> &p->p_realtimer.it_interval); >>>>>> getmicrouptime(&ctv); >>>>>> if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { >>>>>> ntv = p->p_realtimer.it_value; >>>>>> timevalsub(&ntv, &ctv); >>>>>> callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, >>>>>> realitexpire, p); >>>>>> PROC_UNLOCK(p); >>>>>> return; >>>>>> } >>>>>> } >>>>>> /*NOTREACHED*/ >>>>>> } >>>>>> >>>>>> Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as >>>>>> seitimer() above: >>>>>> >>>>>> Index: kern_event.c >>>>>> =================================================================== >>>>>> --- kern_event.c (revision 238365) >>>>>> +++ kern_event.c (working copy) >>>>>> @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) >>>>>> >>>>>> if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { >>>>>> calloutp = (struct callout *)kn->kn_hook; >>>>>> - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), >>>>>> + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, >>>>>> filt_timerexpire, kn); >>>>>> } >>>>>> } >>>>>> >>>>>> -- >>>>>> John Baldwin >>>>>> _______________________________________________ >>>>>> 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" >>>>> >>>>> John, >>>>> I don't think it's good to decrease by a unit the 'ticks' you pass to >>>>> callout_reset_* KPI. >>>>> If this have to be fixed it should be fixed at the callout level and >>>>> not at the consumer level. In other words, subsystems that makes use >>>>> of callout_reset_* should not deal with the inherent limitations of >>>>> callout precision, as it is right now. >>>> >>>> Given that you are reworking callout already, it would seem a bit odd >>>> to rework callout a separate time just to fix this bug. A simple fix >>>> like this (which follows the same pattern we already use for setitimer()) >>>> is something we can easily merge back to 8 and 9. Reworking callout in >>>> a different way than you are already doing, OTOH, is not something we can >>>> merge trivially. >>>> >>>> -- >>>> John Baldwin >>> >>> I understand what you mean. Indeed I hadn't thought about the >>> difficulties of merging that work back. Only a thing: if I'd were you >>> before committing I'd add a comment explaining the reasons of the >>> negative correction in the timeout value passed. >>> >> >> ... and you're going to test the kqueue perioic timer after you make >> your changes to make sure there aren't any regressions? Right? >> > Yes, this is the idea. If you scrolled down here, then probably you have already learned what over-quoting is :-) >> The reason I'm asking is because darwin's bsd subsystem uses the callout >> framework for its kqueue implementation and the periodic timer is of >> course broken. >> >>> Davide >> -- >> Paul Albrecht >> Including signatures into quotes is a sign of a bad mail user agent. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 12:51:09 2012 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 040A8106566B for ; Fri, 20 Jul 2012 12:51:09 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACC928FC08 for ; Fri, 20 Jul 2012 12:51:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SsCfd-0004Go-E7 for freebsd-hackers@freebsd.org; Fri, 20 Jul 2012 14:51:01 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jul 2012 14:51:01 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jul 2012 14:51:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 20 Jul 2012 14:50:50 +0200 Lines: 39 Message-ID: References: <50085193.6030203@gentoo.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB843B65CBADBF2E7187E52BE" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <50085193.6030203@gentoo.org> X-Enigmail-Version: 1.3.5 Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 20 Jul 2012 12:51:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB843B65CBADBF2E7187E52BE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19/07/2012 20:27, Richard Yao wrote: > Dear Everyone, >=20 > FreeBSD 9 has awful block IO performance in KVM. I have experienced it > and others have experienced it. Someone posted slides to slideshare wit= h > benchmarks documenting it: >=20 > http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm >=20 > Slides 13 and 20 are particular eye openers. Does anyone know what is w= rong? I'm interested in seeing if the difference is still large while writing to a raw device (dd of=3D/dev/xxx bs=3D1m count=3D1000) vs writing to the= file system. Can you test this? --------------enigB843B65CBADBF2E7187E52BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJVCoACgkQ/QjVBj3/HSzzcQCeKWOyGCczi54Zi/YLR51iZDnx TakAnjDF3amHhoBbvdcR97F3sbW6Q8lH =7Ryh -----END PGP SIGNATURE----- --------------enigB843B65CBADBF2E7187E52BE-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 19:44:08 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AAFC106567F; Fri, 20 Jul 2012 19:44:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC48C8FC14; Fri, 20 Jul 2012 19:44:07 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7199798pbb.13 for ; Fri, 20 Jul 2012 12:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sykMJcfIEfKoykb/nxeKGL1YsZudx8icywPeDlvZSy8=; b=Xod1q3jem3D9VxrVCGrRht0HuVFo3DzXp5R2n0aqMgYerX3m6F1gyfMB7V91OVd627 cO1ZGp1FozCmzILk/RhvU4af1H0cRnKq/L7pFxNWOvPCADaOZaR4tfsPCNCYu44vBGFc dmc6UEHqN2S+BvB4z+MRu6oBi2EUsnBDVjTzwqtLRD+NGbM4Gw9mEEzE94MN/8rh5KY1 Cw0+iX4qlefR+fpfC2DwfA+L6sjJJdmYV5eaIi05HuZ+RIt43czx/g7/V6wHBwixUtpn FcBGHhdJsidHG9wWLvoMEqd9my0qA82RABw3CYAfQl2ZCtus+oYCEW7ILA4+0WXUg1TV INDA== MIME-Version: 1.0 Received: by 10.68.238.166 with SMTP id vl6mr16246292pbc.96.1342813447305; Fri, 20 Jul 2012 12:44:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.191.138 with HTTP; Fri, 20 Jul 2012 12:44:07 -0700 (PDT) In-Reply-To: <50085193.6030203@gentoo.org> References: <50085193.6030203@gentoo.org> Date: Fri, 20 Jul 2012 12:44:07 -0700 X-Google-Sender-Auth: 95TlZg3AFFLiygyZg7kla8VqQfw Message-ID: From: Adrian Chadd To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Cc: "hackers@FreeBSD.org" , current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 20 Jul 2012 19:44:08 -0000 On 19 July 2012 11:27, Richard Yao wrote: > Dear Everyone, > > FreeBSD 9 has awful block IO performance in KVM. I have experienced it > and others have experienced it. Someone posted slides to slideshare with > benchmarks documenting it: > > http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm > > Slides 13 and 20 are particular eye openers. Does anyone know what is wrong? For those watching at home - this is bad performance _with_ the virtio drivers themselves, not just with SCSI emulation. Slide 17 is very telling - the operation latency is quite high. Richard, are you able to easily test out things on FreeBSD-HEAD guest in a Linux KVM? If so, some of the storage/block/GEOM driver people may be able to step up and start offering some ideas. Thanks, Adrian From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 22:29:04 2012 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 A8520106566B; Fri, 20 Jul 2012 22:29:04 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 832098FC15; Fri, 20 Jul 2012 22:29:04 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 076F51B4092; Fri, 20 Jul 2012 22:29:03 +0000 (UTC) Message-ID: <5009DB2A.7070408@gentoo.org> Date: Fri, 20 Jul 2012 18:26:50 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: Adrian Chadd References: <50085193.6030203@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC8BF3E152CB46B95BB7D2C2" Cc: "hackers@FreeBSD.org" , current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 20 Jul 2012 22:29:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC8BF3E152CB46B95BB7D2C2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/20/2012 03:44 PM, Adrian Chadd wrote: > On 19 July 2012 11:27, Richard Yao wrote: >> Dear Everyone, >> >> FreeBSD 9 has awful block IO performance in KVM. I have experienced it= >> and others have experienced it. Someone posted slides to slideshare wi= th >> benchmarks documenting it: >> >> http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm >> >> Slides 13 and 20 are particular eye openers. Does anyone know what is = wrong? >=20 > For those watching at home - this is bad performance _with_ the virtio > drivers themselves, not just with SCSI emulation. >=20 > Slide 17 is very telling - the operation latency is quite high. >=20 > Richard, are you able to easily test out things on FreeBSD-HEAD guest > in a Linux KVM? If so, some of the storage/block/GEOM driver people > may be able to step up and start offering some ideas. >=20 > Thanks, >=20 >=20 >=20 > Adrian Dear Adrian, I am in the process of setting up a VM instance specifically for this. While installing it, I noticed that qemu-kvm printed 'lsi_scsi: error: ORDERED queue not implemented', which might be a clue as to why the block device performance is bad. Also, I will try testing raw disk IO for Ivan after I have it setup. Yours truly, Richard Yao --------------enigCC8BF3E152CB46B95BB7D2C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCdsqAAoJECDuEZm+6ExkMfgP/2yLB/i7yMQ94GgzPTQad1h2 2HQl4FwdH0dRIZq1qfe+CmWwHqiz5ID86SJnlGMcWyQlWI498N635XI1pTvv1Lbg dIMHwAcWKs/dR4MYmxepKBa+JVUXIcmVT6hoADRFeuaiR8Z+3j917M8FpMKWtRzH mgSs+FgvfF3zj0cbOGdbToEyJkmMpI8oBR/1GMfDqW4qdF6FBNWSf0EG+KUpVsBK RS+dC5RUzUJzCDxMUnXC9DRzEPin7RrRJKqp6rhTDofLmR14fTK4VWqx2dkRncPf UXGIV1L7M5jx3GyC67SiBiXktxPofh/IvBiKf2m5FW8IrnnpSUt6Vl6+CeU4Rr3d PakeTZlEvWXrr2R4NK5jXOrwksX3519wSesgn3kPzlVsbywBG4Wph/FowLBOvj1a Lp+xA9Z9ea0R2WRzsrjpYbqWeRKBV+Tb+bjs7NE/8LyipYiJdIyWL6V9mLoXz5Qo V2UiAZG07/d+Vw7qzSJNlaVVZ6+QAnR3e4BrVLCDBYuckwDuyqbhGpkIXeaVbZ8A oFSYLd/fj5AiBicaV+RdHL5kKRO1vJ372IFlnY670JYWI9+04kfN9mmgk19Qzzok eZVKxPLMvvLn2hEDBHRmASF1uGHk9W4c6sKJgryvmCqYRzJtpwz3G9vmycS7zyj8 i7P46ujM4EQ8I4I/l3Sg =oGTH -----END PGP SIGNATURE----- --------------enigCC8BF3E152CB46B95BB7D2C2-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 22:58:21 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D16B9106564A; Fri, 20 Jul 2012 22:58:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDCE8FC12; Fri, 20 Jul 2012 22:58:21 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7458113pbb.13 for ; Fri, 20 Jul 2012 15:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4p3X3iyTO7dEj0UtSW5FG0N4zUOfySdBxjG9FPZAZ58=; b=wrVKJ/c3s2veVzrGrjWqLMgyxnL+k6w+8QYNKQ+O1EBk1+qaTDnnzahlrNmKdhvZ7r CKm+ROYGK+KjvNY/7KDzCgH8wrq6a28eCBmXoT27UHIbjtPKmn0QWeFe69qPLUoMj8BZ ThcDCindCnQ7CTdGnZEmdtG4sGJSEZ8Ygl+3jT7HhnKPqAN1Jjdbz0+zAe53ArwRn6oO Sb6O7CZVklpRoAhyjmtRZLosI1s14wQxb808oeh7syjS26KxEyKKS7a100yV8Mvv8YKO V8jHkKYN4DGOUsrAN5eD25GwEFrE4+wESam5IbNoPkMDpjKiVoEeNl054+3oHgRexpii qwNA== MIME-Version: 1.0 Received: by 10.68.221.70 with SMTP id qc6mr17578645pbc.92.1342825101453; Fri, 20 Jul 2012 15:58:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.191.138 with HTTP; Fri, 20 Jul 2012 15:58:21 -0700 (PDT) In-Reply-To: <5009DB2A.7070408@gentoo.org> References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> Date: Fri, 20 Jul 2012 15:58:21 -0700 X-Google-Sender-Auth: flW4Xf_yHKyD2G5cG3t8HXazizs Message-ID: From: Adrian Chadd To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Cc: "hackers@FreeBSD.org" , current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 20 Jul 2012 22:58:21 -0000 On 20 July 2012 15:26, Richard Yao wrote: > I am in the process of setting up a VM instance specifically for this. > While installing it, I noticed that qemu-kvm printed 'lsi_scsi: error: > ORDERED queue not implemented', which might be a clue as to why the > block device performance is bad. > > Also, I will try testing raw disk IO for Ivan after I have it setup. Thanks for setting this up. Setting up an easily reproducible environment is by far the biggest and most helpful step here. Adrian From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 02:30:17 2012 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 EA09B106564A; Sat, 21 Jul 2012 02:30:16 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id BCB548FC08; Sat, 21 Jul 2012 02:30:09 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 245041B404F; Sat, 21 Jul 2012 02:30:07 +0000 (UTC) Message-ID: <500A13A6.7030503@gentoo.org> Date: Fri, 20 Jul 2012 22:27:50 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: Adrian Chadd References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> In-Reply-To: <5009DB2A.7070408@gentoo.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD9FC2196913C94EE702A8575" Cc: "hackers@FreeBSD.org" , current@freebsd.org, ivoras@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 21 Jul 2012 02:30:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9FC2196913C94EE702A8575 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/20/2012 06:26 PM, Richard Yao wrote: > On 07/20/2012 03:44 PM, Adrian Chadd wrote: >> On 19 July 2012 11:27, Richard Yao wrote: >>> Dear Everyone, >>> >>> FreeBSD 9 has awful block IO performance in KVM. I have experienced i= t >>> and others have experienced it. Someone posted slides to slideshare w= ith >>> benchmarks documenting it: >>> >>> http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm >>> >>> Slides 13 and 20 are particular eye openers. Does anyone know what is= wrong? >> >> For those watching at home - this is bad performance _with_ the virtio= >> drivers themselves, not just with SCSI emulation. >> >> Slide 17 is very telling - the operation latency is quite high. >> >> Richard, are you able to easily test out things on FreeBSD-HEAD guest >> in a Linux KVM? If so, some of the storage/block/GEOM driver people >> may be able to step up and start offering some ideas. >> >> Thanks, >> >> >> >> Adrian >=20 > Dear Adrian, >=20 > I am in the process of setting up a VM instance specifically for this. > While installing it, I noticed that qemu-kvm printed 'lsi_scsi: error: > ORDERED queue not implemented', which might be a clue as to why the > block device performance is bad. >=20 > Also, I will try testing raw disk IO for Ivan after I have it setup. >=20 > Yours truly, > Richard Yao >=20 I now have FreeBSD 9.1-BETA1 installed in a virtual machine. I noticed the following in dmesg which might explain why the emulated SCSI support is so slow: da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 409600MB (838860800 512 byte sectors: 255H 63S/T 52216C) It does not explain why virtio is slow though, although I still need to test virtio against the latest code. I will do ivan's raw block test against virtio-blk, mainly because there is no point in doing it against a device whose transfers have been capped to 3.3MB/sec. --------------enigD9FC2196913C94EE702A8575 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQChOpAAoJECDuEZm+6ExkWo4P/3O1QiiK9lu6NGfnEmduwhzo NE6Oi1I/CEYkKwhxM8sjmM01vUsmnfcS+uJ1PyT1Ncdnz91FT6AA8wM1ifM+RUdz qgzZOywLfgIDoxOdvefGejg8eFhFMae4L0FiMAZBiS3NO7S8ys1fOSCZvOAnuAAL pYihDi/v94k/tIh3vIzREQff+24DHb2c6o2ZFQDquu0H/3b6pL3/rDMKquNQ7zzG KmRR3iaGc6EZxVdez8cYB8093zmiZaUWScvbVR08DPJljBetCA5jKoR5+PcdE5FE 5W4UJizOuGY3/uabvbOGRGxL1Y2HUtU4F5QsjLGOArqBazUQr5gYX4Ha1lAaPqc3 4UNLoC+oEUZo6+ZVjM8HuVNyO/PFxap6lg3klMrj1AwE9UX1eOpUoW0817rQM/RI ApGQSz809CZe8oIJTdCBE/OParyOGMoqS9lYfl/hqVrCBFbMlxNXisdiczsJPPkT QnDvCywISWMXlhPSJDeH9EeO6+ZUK1bYPZEA4vLCWGdXJ18e085RJIjQ55Hvwira RtC5djfanTPsPk35KKyM6eqvcf+95QnK0da6NFoACF9olLXUY1UgoYF3MuWi3Rf2 QpDK1sIkwdsVT+id4UwYIWxCNhHt9QIwEOAn3jKD3QvS+AQZ6Ezu6dPwuK9Olj53 rszGbmHsQbSJCap9jGdR =XdrQ -----END PGP SIGNATURE----- --------------enigD9FC2196913C94EE702A8575-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 08:15:19 2012 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 6DF9F106564A; Sat, 21 Jul 2012 08:15:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id C849E8FC1C; Sat, 21 Jul 2012 08:15:18 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6L8FFeY001594; Sat, 21 Jul 2012 10:15:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6L8FFSs001591; Sat, 21 Jul 2012 10:15:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 21 Jul 2012 10:15:15 +0200 (CEST) From: Wojciech Puchar To: Richard Yao In-Reply-To: <500A13A6.7030503@gentoo.org> Message-ID: References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> <500A13A6.7030503@gentoo.org> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 21 Jul 2012 10:15:15 +0200 (CEST) Cc: Adrian Chadd , "hackers@FreeBSD.org" , current@freebsd.org, ivoras@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM 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, 21 Jul 2012 08:15:19 -0000 > da0: Fixed Direct Access SCSI-5 device > da0: 3.300MB/s transfers > da0: Command Queueing enabled > da0: 409600MB (838860800 512 byte sectors: 255H 63S/T 52216C) > > It does not explain why virtio is slow though, although I still need to > test virtio against the latest code. I will do ivan's raw block test > against virtio-blk, mainly because there is no point in doing it against > a device whose transfers have been capped to 3.3MB/sec. are you sure it is really capped? i am not. just emulated sym device reports low speed. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 23:51:02 2012 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 87F4C106566C for ; Sat, 21 Jul 2012 23:51:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 597B18FC1C for ; Sat, 21 Jul 2012 23:51:02 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so9142043pbb.13 for ; Sat, 21 Jul 2012 16:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=OdyqgEXN+y5GkKU/x1IiwVMl8wlwIbWGT+kcb9NT7+I=; b=Z6c6Vqj8pwnNKWKSEfytzHWsjyqyUrWBJgBjgDjqz1t2gExWuoNrCfD1hdbt+IFlLS 6jmIO4tDxcEbe7x5YKAz92SFUJJ3d98kSSYNmACgFfRDYOZkfVz1Gk7ovFF5lqfoomwO NOq0GWbiVQlcRP8u0mjSPDx5JLfb3wLGSIbpkhTPBuEZpeFTIRZhYA/AaBoiRmYhjTDN VZKpvjAeiGok22x6UtSNl/9L15BRtf3YeGPPS6lnzGb6/lZ/VfH/jpN3Jyg+UArIARrM wHHv2c3rXcKP5ylm5VYr8KnFZBCn6AJTq1OjcTEmEw660qq24Jx00axO1gtW6nE3c3Xw SD9A== MIME-Version: 1.0 Received: by 10.66.84.7 with SMTP id u7mr8718973pay.83.1342914655982; Sat, 21 Jul 2012 16:50:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.191.138 with HTTP; Sat, 21 Jul 2012 16:50:55 -0700 (PDT) In-Reply-To: <201207212350.q6LNo2Lh061635@freefall.freebsd.org> References: <201207212348.q6LNmjO9084188@red.freebsd.org> <201207212350.q6LNo2Lh061635@freefall.freebsd.org> Date: Sat, 21 Jul 2012 16:50:55 -0700 X-Google-Sender-Auth: xexQpSohJu-9gCM1rsjKq57wHS8 Message-ID: From: Adrian Chadd To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Fwd: kern/170058: [cbb] cardbus slot is not functioning correctly after a resume 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, 21 Jul 2012 23:51:02 -0000 Hi all, I found this in stable/9. I think it's also a problem in -HEAD. Would someone with PCI bus clue take a look ? Thanks! Adrian ---------- Forwarded message ---------- From: Date: 21 July 2012 16:50 Subject: Re: kern/170058: [cbb] cardbus slot is not functioning correctly after a resume To: Adrian Chadd Thank you very much for your problem report. It has the internal identification `kern/170058'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=170058 >Category: kern >Responsible: freebsd-bugs >Synopsis: [cbb] cardbus slot is not functioning correctly after a resume >Arrival-Date: Sat Jul 21 23:50:02 UTC 2012