From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 02:25:07 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 540D5106564A; Sun, 16 Sep 2012 02:25:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 26BD48FC12; Sun, 16 Sep 2012 02:25:07 +0000 (UTC) Received: from glenbarber.us (75.97.141.105.res-cmts.sewb.ptd.net [75.97.141.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 53BA723F6D9; Sat, 15 Sep 2012 22:25:04 -0400 (EDT) Date: Sat, 15 Sep 2012 22:25:02 -0400 From: Glen Barber To: Alfred Perlstein Message-ID: <20120916022502.GC1354@glenbarber.us> References: <20120915205349.GF34563@elvis.mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <20120915205349.GF34563@elvis.mu.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 02:25:07 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 15, 2012 at 01:53:49PM -0700, Alfred Perlstein wrote: > This sounds like a plan. >=20 > I apologize if my mail wasn't clear, it was jokish in nature. >=20 > To clarify: I firmly support removal of CVS from HEAD. >=20 I'm in the same boat here, to be honest. Glen --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQVTh+AAoJEFJPDDeguUaj8tUIALAsMbo1l7KlssPJWKHFcCyN rjHday5Mk9WaxuoiL/4P5k4FfhdGXiI5cKUkSiFBKetkkAYU3hucR4YS9cKyjI/k 5stZUwZnoyZWpT/Sd3GAY5K2lVq3o89ob0PP+3cVmpGvv4K93oQgtKt64gDeh+bL nvO4orqRe3JG563vyoA9pholZTtzCYwhCYLGcCE64nC2faw6DdYMojimWaTGKaBo 9otEhkhHvbyi2XKCiEt7nR1oWZs1zYAX1Qgo6o7hZCL1UHrfBnvzqmFU3X27fXc6 GwGfaquidLrsayDJIBitqXSl9jdlqsVsUECtwSVKSKmb3nCJQlwzP9X1bgA+Wqg= =wLnR -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 02:32:00 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CB91065674 for ; Sun, 16 Sep 2012 02:32:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id B573E8FC12 for ; Sun, 16 Sep 2012 02:31:58 +0000 (UTC) Received: by iea17 with SMTP id 17so5125096iea.13 for ; Sat, 15 Sep 2012 19:31:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kTDOiUf0s4Ba3EnfGukkyjdgJWmeZKeJqXbcf68psmA=; b=U4tkDq9h/o/lZVdcdEWIWAX44k2wc6tyhp7SVRPaDTm7Sxuzp8awzjWhVjDmNDaaqO wbu3//x5wGlAoORIfPLhrVa3mc2g4usIG/1YeeJywLHWm34sP2CuQFM7qxzDKOWQpB3b lDykWnAAVM6A08z4TSlyxtBZcyrBvguJcHEKAH+dEVgEXTiAucadzfiRDjY3Wm9as41R GFqLu8c5a3MkqdgZmaZWJFYwSr75HXMkwEtwRk15LDoIcoPwtpFaDouUCaPJpYSijjFa Uc2dv0SyzH+QAxpUpmsUV2946cceOtGm6EIt4f+Tmy/ALbAeeq77Q/fdvk6nyP1t1/w/ acWw== Received: by 10.50.195.233 with SMTP id ih9mr3270659igc.65.1347762718044; Sat, 15 Sep 2012 19:31:58 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wg9sm5188042igb.0.2012.09.15.19.31.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Sep 2012 19:31:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120916022502.GC1354@glenbarber.us> Date: Sat, 15 Sep 2012 20:31:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <096AB660-5016-4D19-93B8-7B36E58B5827@bsdimp.com> References: <20120915205349.GF34563@elvis.mu.org> <20120916022502.GC1354@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnq5J2xHjgbf9iJwGiPCruafjM5RWLTdUcCk8Gd0UXB3ikHXBJadv8UIlwqoG4HFU/sr+HQ Cc: Eitan Adler , Alfred Perlstein , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 02:32:00 -0000 On Sep 15, 2012, at 8:25 PM, Glen Barber wrote: > On Sat, Sep 15, 2012 at 01:53:49PM -0700, Alfred Perlstein wrote: >> This sounds like a plan. >>=20 >> I apologize if my mail wasn't clear, it was jokish in nature. >>=20 >> To clarify: I firmly support removal of CVS from HEAD. >>=20 >=20 > I'm in the same boat here, to be honest. I oppose the premature removal of cvs. I support the mature removal of = cvs. We've botched a number of other transitions. Since it isn't that = hard to get our ducks in a row for this one, we should do that and then = remove. It is a pita to me, since I keep all my dot files in cvs, but I was = thinking of moving over to git anyway... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 03:13:05 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00DCD106566C; Sun, 16 Sep 2012 03:13:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id CA39E8FC0A; Sun, 16 Sep 2012 03:13:04 +0000 (UTC) Received: from glenbarber.us (75.97.141.105.res-cmts.sewb.ptd.net [75.97.141.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 0DE9823F6D9; Sat, 15 Sep 2012 23:13:01 -0400 (EDT) Date: Sat, 15 Sep 2012 23:13:00 -0400 From: Glen Barber To: Warner Losh Message-ID: <20120916031300.GD1354@glenbarber.us> References: <20120915205349.GF34563@elvis.mu.org> <20120916022502.GC1354@glenbarber.us> <096AB660-5016-4D19-93B8-7B36E58B5827@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <096AB660-5016-4D19-93B8-7B36E58B5827@bsdimp.com> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eitan Adler , Alfred Perlstein , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 03:13:05 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 15, 2012 at 08:31:55PM -0600, Warner Losh wrote: > >> To clarify: I firmly support removal of CVS from HEAD. > >>=20 > >=20 > > I'm in the same boat here, to be honest. >=20 > I oppose the premature removal of cvs. I support the mature > removal of cvs. We've botched a number of other transitions. Since > it isn't that hard to get our ducks in a row for this one, we should > do that and then remove. >=20 For the record, I was only clarifying my point of view on the topic. (Off-topic, maybe this is the appropriate time to recommend the use of tools such as cfengine for dot-files, etc. Then, the backend VCS is used only to commit/checkout, and otherwise is irrelevant.) Glen --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQVUO8AAoJEFJPDDeguUajOcoIAKoKWgZsF3pArUFhhlGpp8cs ZZlT2ZX0sGVZDMRyKeg7A71mnLJXhUYz9rbMFRa6AwRVRnxfIIqs9kkhPC+iMAMV rOk+tvJkSc6nuwLZjMlQ+WfkLNIgbQEnd2OSFr8gXRrPJTibsvK4HccWmzyO4Z0i 4aPA1jOcFRLuNGuwmWTWAtnTXtU6K01s+jaJyHhf1HcoljugvbxlW5z1/rKJgMKr GZtj0S98RbHQjG5F8G8l1DUl2O6cwH2DjwsNjM9pl6wPJ/FfyiWgJ+I9Tqe1G+7+ O7Tmol1zpVqDyIkFTEwKp5BmTNmyuS8/mMHdX2jSzFn0vmhvOX4jg1E4i4H6GwY= =01PG -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 05:35:29 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1112106564A for ; Sun, 16 Sep 2012 05:35:29 +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 3B25B8FC08 for ; Sun, 16 Sep 2012 05:35:28 +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 q8G5ZZpJ047257; Sun, 16 Sep 2012 08:35:36 +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 q8G5ZNNj026304; Sun, 16 Sep 2012 08:35:23 +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 q8G5ZNwB026303; Sun, 16 Sep 2012 08:35:23 +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, 16 Sep 2012 08:35:23 +0300 From: Konstantin Belousov To: Eitan Adler Message-ID: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wv56KCa6/aA7yLgk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 05:35:29 -0000 --wv56KCa6/aA7yLgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: Removing the whole CVS discussion above, want to answer to seemingly unrelated note in your email, which I see as continuing very disturbing trend. > However, -CURRENT is not meant to be a production system. It is simply not true. CURRENT shall never be knowingly put into a state where it cannot be used for the 'production-grade' use, whatever it means. We do accept changes are so disruptive that some unknown fallout is expected, since otherwise developers cannot make any significant progress. But introducing known breakage is simply not acceptable. Doing so shrinks the already limited testing base we have for HEAD. --wv56KCa6/aA7yLgk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBVZRsACgkQC3+MBN1Mb4g+jACeK6zb71fv2yRNzMHKqhd3HSdq L/QAnikBrFEor43F9gSdQAjOu3Xm+0gU =5b1Y -----END PGP SIGNATURE----- --wv56KCa6/aA7yLgk-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 05:40:41 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4131A106564A for ; Sun, 16 Sep 2012 05:40:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 006338FC08 for ; Sun, 16 Sep 2012 05:40:40 +0000 (UTC) Received: by iea17 with SMTP id 17so5217000iea.13 for ; Sat, 15 Sep 2012 22:40:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=YgnC2ADRs+bXjgKGm25RZed6EdcV583HiotcISC/eqM=; b=H3+KaLKGvpVXq1+CbZKuGWOPzlO1F5gCWEkoGRCHi9qr5tBghVwXGP5nyXzrzfiT+h d20sfy5wM5fTsauc5fQbM7t8x5AoCvgUtai4NybNkCExtbv7FtG7uWNrVMzlW/QaeaSf Ry/FpXcDD//XCXh4MEbOo2ojoxOJUeyEOnXELuI1jGeA7eoHIqzZ9C5DSjNxYf9HbKaC K/YnSwBtSzyR8JnXzSzVcRSBJDe03SluWumd67xFxKdVw61lIEPdu/YhPOtid6ZPW0mF SkwS1FCWy6JKUILG6/rp9adBgOd73O+MyP2FJVzsmoE+4vB5UBmeBpy2ycsJ8qYkgHkx SvEQ== Received: by 10.42.95.148 with SMTP id f20mr6148296icn.20.1347774039913; Sat, 15 Sep 2012 22:40:39 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id va9sm3304809igb.17.2012.09.15.22.40.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Sep 2012 22:40:38 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> Date: Sat, 15 Sep 2012 23:40:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQktwBiyXw2Doxq5c082uNoVzPvyNgNrYtvcuio9t/zN54JQeThTQVF4RzPMGzNHNoeaS8fU Cc: Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 05:40:41 -0000 On Sep 15, 2012, at 11:35 PM, Konstantin Belousov wrote: > On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: >=20 > Removing the whole CVS discussion above, want to answer to seemingly > unrelated note in your email, which I see as continuing very = disturbing > trend. >=20 >> However, -CURRENT is not meant to be a production system. >=20 > It is simply not true. CURRENT shall never be knowingly put into a = state > where it cannot be used for the 'production-grade' use, whatever it > means. We do accept changes are so disruptive that some unknown = fallout > is expected, since otherwise developers cannot make any significant > progress. >=20 > But introducing known breakage is simply not acceptable. Doing so = shrinks > the already limited testing base we have for HEAD. That, in a nutshell, is why I've been beating on the 'we have to tie up = the loose ends we know about before pulling the trigger' drum... That = should be people's first thought before they make major changes in = FreeBSD. For a better handled thread, look at the clang discussions = when the warnings were sent out of the cut over. MANY things have come = to light in that discussion which were little known, and they should be = fixed... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 06:14:31 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 390FD1065670; Sun, 16 Sep 2012 06:14:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A245F8FC08; Sun, 16 Sep 2012 06:14:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 6B6B23B74B; Sun, 16 Sep 2012 06:14:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8G6ETko080896; Sun, 16 Sep 2012 06:14:29 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 15 Sep 2012 13:53:49 MST." <20120915205349.GF34563@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 16 Sep 2012 06:14:29 +0000 Message-ID: <80895.1347776069@critter.freebsd.dk> Cc: Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 06:14:31 -0000 In message <20120915205349.GF34563@elvis.mu.org>, Alfred Perlstein writes: >I'm also a bit troubled that something that makes so much >sense blew up into such a large discussion. There's an entire domain for that: bikeshed.org -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 12:34:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 819661065670 for ; Sun, 16 Sep 2012 12:34:54 +0000 (UTC) (envelope-from lists@eitanadler.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 4DBCB8FC12 for ; Sun, 16 Sep 2012 12:34:54 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8406334pbb.13 for ; Sun, 16 Sep 2012 05:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3F5vjzm+Alx8blcY0ZEqTT8/OqvoG1lKlsaBjprKAUw=; b=HekSZSF+PyEvqfKwS8EHhyrF76tCaoxQ2+iNAf8K29fahu+CIivrbnRbnKu2jRdeB4 V5xbsxKVBUiocpzpvaG/mH848aP49D45l0Tp0LUM5KnZDUsZ755FXp3ERw0zAlCIqIk8 irut6yLvKT04irMPdjKgUh5h+jv4HlfvaBxdw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3F5vjzm+Alx8blcY0ZEqTT8/OqvoG1lKlsaBjprKAUw=; b=SVuh+GZC07ONAT8VFgUM7RX/LntZZDrj5S0Qq/iCSr/rZyS5eEnavg7Wm/uW+TT2Tq XLp5nl3UxsZkwbWKM/gzVpHNe03rk4uNkMmJ7dLjUanSX+tuBUO/zKBXFV19oxdJLSBe huLVIIX4go8WogR2n0ffuWf0ilTJKibfARl/Oed46RcxQr+DxhnGLQq3bppS+KpTL7iK bN//K4lX28o/7BpBv2xO35tVmVOolr8dz0GsGhtqH1gdieU59Knrfjooi5pBxxXHOZh8 YkZBAmlC2GXuZFB4ORPDzwkCVAGH+/zFzEw7Sv+iWUgvBLpoe7lGGM5uicyrpPoRI1Fk wtyA== Received: by 10.68.213.195 with SMTP id nu3mr15707640pbc.81.1347798893856; Sun, 16 Sep 2012 05:34:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.41 with HTTP; Sun, 16 Sep 2012 05:34:23 -0700 (PDT) In-Reply-To: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> From: Eitan Adler Date: Sun, 16 Sep 2012 08:34:23 -0400 Message-ID: To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl0AGx2qD9ERxu9EPYBzaxJUdOV8D4WN66gcKvLlbHZAOYIhR+A8dcg4CFLaq5d+xg9AdUG Cc: arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 12:34:54 -0000 On 16 September 2012 01:35, Konstantin Belousov wrote: > On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: >> However, -CURRENT is not meant to be a production system. > > It is simply not true. My statement was true, but does not disagree with the content below. Production system != Production Grade. > CURRENT shall never be knowingly put into a state > where it cannot be used for the 'production-grade' use, whatever it > means. Agreed. > We do accept changes are so disruptive that some unknown fallout > is expected, since otherwise developers cannot make any significant > progress. The point of my statement is that it perfectly acceptable to change behavior in HEAD in a non-backwards compatible way. In particular no systems running -CURRENT are expected to be "critical functioning". People that track -HEAD are expected to be able to deal with the sorts of problems that occur from "drastic change." > But introducing known breakage is simply not acceptable. Doing so shrinks > the already limited testing base we have for HEAD. Agreed. -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 16:03:25 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F81C106566B for ; Sun, 16 Sep 2012 16:03:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE198FC08 for ; Sun, 16 Sep 2012 16:03:24 +0000 (UTC) Received: by iea17 with SMTP id 17so5616203iea.13 for ; Sun, 16 Sep 2012 09:03:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mtJdZ1Oz2SpJKUzy/J+2a65K+zKSqTtkvrVmcer7c7c=; b=A5/U6+8iWvbV8KkCDCC6g01UlOA0ksItsla3bWRr6X8sidtvMTuYERXAUTP+Ivdrx2 ry7xwtD6n3Gq5c1MZcVvJZlLoyLw0sZFhhMJRdxqvoP65BY0YlYBPNSSD68GMGfXT9w8 2IXRtkrUeLhRPDa67KR1D9+nHVl+zE7JyVKgMceoHG6FP1GpRt1fX/85sLiynGZR0Xgs DX562B8Ien/u4ES9HCJtDogLJ+qULUh2qJgD8Y2NhK3Fu8fWXzsSHRX+ScN0Y43zo5LV ad+2GIV9J+H+y/HWMHFjhh0VbViaR74gKC8PnHA5WYQYy5YvyXmTCK8lMaC7cartvvLc dgfg== Received: by 10.50.12.138 with SMTP id y10mr4397174igb.53.1347811403811; Sun, 16 Sep 2012 09:03:23 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id d19sm4514252igp.6.2012.09.16.09.03.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:03:22 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 16 Sep 2012 10:03:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> To: Eitan Adler X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkY0jY95203dtYT/QL5reUJIDvCBe7ppoOX4JCnnfPZMnRupdwtYobYONKNR0/f3MzQqiDH Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 16:03:25 -0000 On Sep 16, 2012, at 6:34 AM, Eitan Adler wrote: > On 16 September 2012 01:35, Konstantin Belousov = wrote: >> On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: >>> However, -CURRENT is not meant to be a production system. >>=20 >> It is simply not true. >=20 > My statement was true, but does not disagree with the content below. > Production system !=3D Production Grade. One of the things we are trying to move towards is that current can be = cut into a release branch on short notice. We need to keep it as close = to production ready as possible. People do put -current systems into = production for testing purposes, or because they have made the = evaluation and know what they are doing. Discouraging production = systems from current, the present project policy, doesn't mean the = project doesn't appreciate the people that do put current systems into = production and the data that generates. Put another way: saying that current isn't meant for production systems = as a justification to slash things out before we are quite ready isn't = something people in general want to encourage, since it is close to = attitudes in the past that got us into a lot of trouble. Sure, in this = case the reaction is a bit of hyperbole, but there's long, historically = lingering wounds that put people on a hair trigger. >> CURRENT shall never be knowingly put into a state >> where it cannot be used for the 'production-grade' use, whatever it >> means. >=20 > Agreed. >=20 >> We do accept changes are so disruptive that some unknown fallout >> is expected, since otherwise developers cannot make any significant >> progress. >=20 > The point of my statement is that it perfectly acceptable to change > behavior in HEAD in a non-backwards compatible way. Some behaviors, yes. Most behaviors need to remain the same for a = variety of reasons. > In particular no > systems running -CURRENT are expected to be "critical functioning". Yes, they often are. > People that track -HEAD are expected to be able to deal with the sorts > of problems that occur from "drastic change." Generally yes. However, we do try to cushion the blows that are = delivered in -current. The reason we have the separation isn't so we = can do whatever we want in -current, it is so that when somebody messes = up, the damage is more limited. >> But introducing known breakage is simply not acceptable. Doing so = shrinks >> the already limited testing base we have for HEAD. >=20 > Agreed. Ditto. Sorry to be so pedantic on pushing the point in this meta-discussion, = but I don't want to see us slide back into the 'wild west' that current = was in the 5-current time frame. The CVS thing, by itself, wouldn't do = that, but we must have the proper attitudes for getting change done, and = when we pull the trigger on change. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 17:53:46 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2B83106566C for ; Sun, 16 Sep 2012 17:53:46 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 542B18FC0A for ; Sun, 16 Sep 2012 17:53:45 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so4579462lbb.13 for ; Sun, 16 Sep 2012 10:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=cFqBiKFQkvYbWgkomeyPlkcrkAPyPUhPduMkflidtLI=; b=JNsRjkFQixhQGucX8IjDWJB4EbFZq0nHC6RtCiZVak+9CVSyFXhKTbOZeczju3pd60 fSver56h2shYAGohbyxxwlBQMcNXLr6xKOL93GsfNLK2Dt5YysssCFP+7AHFun/YWKDP VShsjiE5ypoZdxu6W7OUWDZZGv3iiTlj9gF9B/dMhHvnArT8hUhAXOvuIsgZ68gdI1bK GTRYxRi9A5ACcWdSdvNrxHr0n36pOXWiP5/awfsRAEaTUIVAe/jgG8I8TbKz1vCvyE5B +J/2V/naZID77okDL3OBcy+RPdk+N7hxvEV3zaECl+5XHFXqxw45DICqpRLbD4BvWdx5 RknQ== Received: by 10.112.30.8 with SMTP id o8mr3139870lbh.132.1347818024930; Sun, 16 Sep 2012 10:53:44 -0700 (PDT) Received: from zont-osx.local (ppp95-165-139-113.pppoe.spdop.ru. [95.165.139.113]) by mx.google.com with ESMTPS id ba4sm2015719lbb.14.2012.09.16.10.53.43 (version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 10:53:44 -0700 (PDT) Sender: Andrey Zonov Message-ID: <50561223.7060709@FreeBSD.org> Date: Sun, 16 Sep 2012 21:53:39 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <50463026.8000506@FreeBSD.org> <504653CD.2000707@FreeBSD.org> <5046F4E0.6000606@FreeBSD.org> In-Reply-To: <5046F4E0.6000606@FreeBSD.org> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE218ED8847BBCE1EBCDBCD9" X-Gm-Message-State: ALoCoQkfPTxuzbDVyNum5W6DTcc7Fn0zmh3SsyrQAC5KP/EC/L31vf9NGA2eQu48DeTMnlZ4Df/3 Cc: freebsd-arch@FreeBSD.org Subject: Re: [patch] unprivileged mlock(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 17:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE218ED8847BBCE1EBCDBCD9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/5/12 10:44 AM, Andriy Gapon wrote: > on 04/09/2012 22:17 Andrey Zonov said the following: >> On 9/4/12 8:45 PM, Andriy Gapon wrote: >>> on 30/08/2012 12:06 Andrey Zonov said the following: >>>> Hi, >>>> >>>> So, I've got the first version of the patch (attached) which fixes=20 >>>> memory locked limit checking and accounting. >>> >>> Andrey, >>> >>> your mlock.patch looks good to me, but I haven't verified pieces unde= r >>> RACCT. Please try to get a review from a person who is knee-deep in t= he >>> VM code like alc or your mentor. >>> >> >> Thanks for review! >> >>> The code should also be sent for vetoing to security@. Not sure if y= ou >>> would get a review there, but absence of nays would be good. >>> >>> When the code is ready to be committed, please remember about=20 >>> memorylocked=3Dunlimited in the default entry of the default login.co= nf. A >>> big warning about it will have to be posted (in UPDATING and >>> current@/stable@ at the very least). >>> >> >> After that amd(8), geli(8) and watchdogd(8) will be broken, because th= ey=20 >> call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLOCK= =2E I >> will prepare patches for raising limits if there is no other solution.= >=20 > Thanks for working on this. > BTW, I am not sure why those applications would get broken... > We could/should still have memorylocked=3Dunlimited for the 'root' clas= s. > Or is it about something else? >=20 Hmm, I thought that root login class commented out. >>> Thank you very much for doing this work. >>> >>> P.S. It would probably make sense to provide some HTTP home for this= >>> patch as well. >>> >> >> Updated patch is here [1]. >> >> [1] http://people.freebsd.org/~zont/mlock1.patch >> >=20 > Thank you! > One additional thing - we probably should retire PRIV_VM_MLOCK and > PRIV_VM_MUNLOCK. That would include making changes to > sys/i386/ibcs2/ibcs2_misc.c and sys/ofed/drivers/infiniband/core/umem.c= =2E >=20 They are useful for jails as trasz@ mentioned on IRC. > P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder wh= at was > the intended use for it (if any)... >=20 So, here is the second version of the patch [1]. [1] http://people.freebsd.org/~zont/mlock2.patch --=20 Andrey Zonov --------------enigEE218ED8847BBCE1EBCDBCD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQVhImAAoJEBWLemxX/CvTN0kH/RNV4ZLnUJLNAmiV/ckXP6DV qtkhHOrxIR13FDT73U+Ff47KckAL9JbI4xZ7jBAin7A2Km/X56IKkvUuCCaloL/r vJz62F77O/B+Hh+bPe3Ad6hfym6LKNxbYGLLqHr7f8aRJpGvpHQfZohyJNnviOcz qUD0VNvRbnppcPoNEJ4VUkpgOxV3DoJ9qNFQOSN47ruz+b1iIPnd8ZOl0lybVqVt 0x7MIhvtpl/3rI89PTc4RmqdA71GObFJ8Cmm+sewxARedK+EdP/MwcmzOnCQmrfI FyG4JTlBsYPdq97cklIpEJ09yzkAaayBa8rqC/nuoNs1ANKE+eZ7h8gm3/PKazM= =wjMX -----END PGP SIGNATURE----- --------------enigEE218ED8847BBCE1EBCDBCD9-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 19:53:26 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8155106566C for ; Sun, 16 Sep 2012 19:53:26 +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 97B588FC08 for ; Sun, 16 Sep 2012 19:53:26 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8728294pbb.13 for ; Sun, 16 Sep 2012 12:53:26 -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=Iffuut99ja9X1y1OKYZCIKaMgV9gYoQ1XJ6tozRdfK4=; b=H//88sJiDr9Z6Jwc8IbGoabllcO5lWzsTu6lwo+kP1C8DuxfwdkGmrytR6ap0j/G7N uGB6uZ+2rtfvqGhBTf57jxN+b3eZpv8oZqhV024VTsEW4u0v3lAeuyKjMDepNOMBAVXf N8RvRYT8y2Ma8SZbgmAHbitdf9zO8nEyBD/21rqZoflLI1YNMkJ7f+kmWne19R0V5f8m euus1RmToW3+nnUJT25otOhDvnmRoNANLg0FD3npmUPeXbzdBv0oJ95vZexgdAwr+Q7r IfG+m5HNmCYAB34Ro5ljqlClFYK+XJ11z2gqQvBCMxqrQaGEao8Ee2JfShNxMzdwKJX5 D1sQ== MIME-Version: 1.0 Received: by 10.66.90.38 with SMTP id bt6mr15808295pab.53.1347825205767; Sun, 16 Sep 2012 12:53:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Sun, 16 Sep 2012 12:53:25 -0700 (PDT) In-Reply-To: <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> Date: Sun, 16 Sep 2012 12:53:25 -0700 X-Google-Sender-Auth: gb7Ct0XfTfuZtrNPNOCiNhm2b4I Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 19:53:26 -0000 My personal take on all of this is that it's all very badly "directioned." As in - personally, I think CVS as a package is fine. However: * I'd like to first see a roadmap for doing this - eg, "we're adding a NO_CVS option; CVS will become a port, you can migrate to the CVS port with your next build/installworld"; * if you're that way inclined, backport the NO_CVS option (if it doesn't exist) to -9; * Ensure all of the stuff that uses CVS is migrated beforehand, and publish all of that effort somewhere; * Make sure you're doing it for reasons that aren't coming across as "GPL free! at all costs!" The last is the most important to me. I am beginning to feel that the push for clang, no CVS/RCS, migration to BSD licenced tools, etc is for reasons other than _a sound set of technical and long-term goal reasons_. You run the risk of falling afoul for the same kinds of stupid crap that GPL zealots fall afoul of - you first pick a political/philosophical stance, then you base all your technical decisions on that. Then stir in a bit of cognitive dissonance and suddenly you're coming up with justifications to remove things - when the underlying honest reason is "because it's not BSD licenced." Now, to stir up trouble, I hereby suggest that if you're going to remove CVS because it's no longer used for FreeBSD's project stuff, we should obviously import subversion into the base because _it_ is being used for the FreeBSD project stuff. Think of why you're not doing that (likely because it's already a port/package and there's just as much inertia to introduce something to the base system as there is removing it and making it a port) and see if that helps refocus your reasons for and against doing things. 2c, Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 20:08:28 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F79106566B for ; Sun, 16 Sep 2012 20:08:27 +0000 (UTC) (envelope-from lists@eitanadler.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 AAFEC8FC0A for ; Sun, 16 Sep 2012 20:08:27 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8738404pbb.13 for ; Sun, 16 Sep 2012 13:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4kgAxsfhqpnMxxykSufwH52vqBT+xocjK46JzbEMefA=; b=LRM08eUkEfmP2Vo7+p8fH8cYxf8njbxi18gnKa7XOCNcjQvlEmHfr2GbgL2DXslR1J KOGDAgdvrB2p8Ib8AWxkPk2ljrQgNQVfGsv9Kk8xfcb0sCiUOayX1AHLpcj62npmz20d hr0y+BMRjnYwDTOnTGuWfmYR5J3qOTddtKeR8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4kgAxsfhqpnMxxykSufwH52vqBT+xocjK46JzbEMefA=; b=NKzfiWfVfqaW3rjlaVOnliP6ykseyhEi+TTGLNRWuRftm2YIhlhWmBzx17rObotkxj waEJP0PgA6qjlKeuyLlYfCll0w6pT5dsfrwlemfurbtK/xx8GBXNDaqF8nVtEr7QN5L5 44mSwBYnu5LoISHax9vTP8iGEhOztrQqemGJfFmZBNVYvh08dvITdPtR0HRHWIeHbOHq W8pHNi6zHhKHVYpj4owy0SVRHiRuJhuA6fkEwce9wywT84jguzyibs9gj0Esut9qDtv/ 80tXmcXwnaeifuG1P4gtmxyk9jM/vJN9MjMVB7+VfDATmksR5MdWDxdkXF8gKtty3CRd 50uw== Received: by 10.68.130.65 with SMTP id oc1mr17904016pbb.29.1347826107276; Sun, 16 Sep 2012 13:08:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.41 with HTTP; Sun, 16 Sep 2012 13:07:56 -0700 (PDT) In-Reply-To: References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> From: Eitan Adler Date: Sun, 16 Sep 2012 16:07:56 -0400 Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkGPusuDzPvlKt9yJA8xllZVLjW6GX85RGHfqX2B3ko/+aN/cbw/tcSJ1p7QeIyCZVVjMfO Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 20:08:28 -0000 On 16 September 2012 15:53, Adrian Chadd wrote: > * I'd like to first see a roadmap for doing this - eg, "we're adding a > NO_CVS option; CVS will become a port, you can migrate to the CVS port > with your next build/installworld"; We have WITHOUT_CVS . > * if you're that way inclined, backport the NO_CVS option (if it > doesn't exist) to -9; Already done. > * Ensure all of the stuff that uses CVS is migrated beforehand, and > publish all of that effort somewhere; This is part of my plan. > * Make sure you're doing it for reasons that aren't coming across as > "GPL free! at all costs!" This has nothing to do with the reasons I proposed to remove CVS. Please re-read my original email. The first words were "CVS is obsolete." I had *no idea* CVS was GPLed until the thread started (I thought were using a BSD licensed one). > Now, to stir up trouble, I hereby suggest that if you're going to > remove CVS because it's no longer used for FreeBSD's project stuff, we > should obviously import subversion into the base because _it_ is being > used for the FreeBSD project stuff. Please re-read the original thread. I am removing CVS because it is obsolete. CVS being used for FreeBSD project was merely a key blocker to its removal. > Think of why you're not doing that > (likely because it's already a port/package and there's just as much > inertia to introduce something to the base system as there is removing > it and making it a port) and see if that helps refocus your reasons > for and against doing things. I am not proposing introducing subversion into base because I am not willing to do the work to maintain it. If I were, that would be a different story (imho, the base should have sufficient software to download and compile itself). -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 20:53:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63554106564A; Sun, 16 Sep 2012 20:53:54 +0000 (UTC) (envelope-from yanegomi@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 2753B8FC0A; Sun, 16 Sep 2012 20:53:53 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8766851pbb.13 for ; Sun, 16 Sep 2012 13:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8RK/Oau7PgqXk0+bVrT1A2EjsmFydSOTVXQmWEZM/vg=; b=oj4PaQvw2tx+IdtKKuuafULLhI9c35vlRzWOWHjKOpWqDGGBskZc/fc+x0B8fVqKI8 k5DJDbp0g+M9+FjL/JF7SXUWG3c5cKf6l+zB9zefZa81mJiACdLtHKNPNkjtyuIpyL9R mnqr8yuJC8WPU9Zyq/InDYiayTVFriFHScb6xcvUlBFfyjP+yVhqvMQ426WlEvxr2irh pArsAQv0EizmxWJNazKhlBrGkLofmUxghYYGhYiECHdmUSm3l1o8i8Pqv6gDL1YUFkfT BgLhB2gHuUro1UTB15dSIg38tXRkPM4RH7ml7uO+26N4cuQuU5uFhyT35rHNbD0dIDNt TjBA== Received: by 10.68.217.202 with SMTP id pa10mr18462583pbc.15.1347828833584; Sun, 16 Sep 2012 13:53:53 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id pn4sm5642741pbb.50.2012.09.16.13.53.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 13:53:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 16 Sep 2012 13:53:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68E67617-A497-48FB-9B63-1AAC06BD60DA@gmail.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> To: Eitan Adler X-Mailer: Apple Mail (2.1278) Cc: Konstantin Belousov , arch@freebsd.org, Adrian Chadd Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 20:53:54 -0000 On Sep 16, 2012, at 1:07 PM, Eitan Adler wrote: > On 16 September 2012 15:53, Adrian Chadd wrote: >=20 >> * I'd like to first see a roadmap for doing this - eg, "we're adding = a >> NO_CVS option; CVS will become a port, you can migrate to the CVS = port >> with your next build/installworld"; >=20 > We have WITHOUT_CVS . >=20 >> * if you're that way inclined, backport the NO_CVS option (if it >> doesn't exist) to -9; >=20 > Already done. >=20 >> * Ensure all of the stuff that uses CVS is migrated beforehand, and >> publish all of that effort somewhere; >=20 > This is part of my plan. >=20 >> * Make sure you're doing it for reasons that aren't coming across as >> "GPL free! at all costs!" >=20 > This has nothing to do with the reasons I proposed to remove CVS. > Please re-read my original email. The first words were "CVS is > obsolete." > I had *no idea* CVS was GPLed until the thread started (I thought were > using a BSD licensed one). >=20 >> Now, to stir up trouble, I hereby suggest that if you're going to >> remove CVS because it's no longer used for FreeBSD's project stuff, = we >> should obviously import subversion into the base because _it_ is = being >> used for the FreeBSD project stuff. >=20 > Please re-read the original thread. I am removing CVS because it is > obsolete. CVS being used for FreeBSD project was merely a key blocker > to its removal. >=20 >> Think of why you're not doing that >> (likely because it's already a port/package and there's just as much >> inertia to introduce something to the base system as there is = removing >> it and making it a port) and see if that helps refocus your reasons >> for and against doing things. >=20 > I am not proposing introducing subversion into base because I am not > willing to do the work to maintain it. If I were, that would be a > different story (imho, the base should have sufficient software to > download and compile itself). 1. Subversion changes too much to be in base (its release cycle is = shorter than bind). 2. Subversion sometimes breaks between major/minor versions (1.6->1.7 = comes to mind) and is not backwards compatible in many cases (again, 1.6 = -> 1.7 transition). 3. It requires apr (which optionally requires gdbm), BDB 4.x (which is = GPLv2/GPLv3), sqlite3 (which pulls in tcl because of the distfile the = sqlite3 maintainer chooses to use), neon or serf, etc (point is the = dependency list is not short and thus maintainer overhead is = considerably higher). Please leave it in packages/ports. With pkg_install/pkgng, installing = subversion from a package is trivial and that should be the route taken = for developers, as opposed to having a copy in base. Thanks, -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 21:03:35 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 291801065670 for ; Sun, 16 Sep 2012 21:03: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 81A6E151DF8; Sun, 16 Sep 2012 21:03:34 +0000 (UTC) Message-ID: <50563EA6.1050908@FreeBSD.org> Date: Sun, 16 Sep 2012 14:03:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warner Losh References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> In-Reply-To: <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:03:35 -0000 On 09/16/2012 09:03, Warner Losh wrote: > One of the things we are trying to move towards is that current can be cut into a release branch on short notice. We need to keep it as close to production ready as possible. People I find your response here interesting Warner, given that when I have opposed what I felt were too-drastic changes in HEAD (such as removing sysinstall before a post-install configuration solution was ready) your response has been, "It's HEAD, we can break things ... let's see what happens!" Now that you are the one opposed to the change, we need to keep HEAD "close to production ready." There is a compromise solution here that I have been hesitant to offer because I was really hoping that sanity would prevail. But why not switch the default MK_CVS knob over to "no" now? That will give us an opportunity to see if there really will be any fallout, and easily fix it if there is. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 21:06:00 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F060106566B; Sun, 16 Sep 2012 21:06:00 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 519598FC0A; Sun, 16 Sep 2012 21:06:00 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q8GL5qYY003129; Sun, 16 Sep 2012 21:05:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ihvkif9jtpjitkn59ajvzwa2xe; Sun, 16 Sep 2012 21:05:52 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <68E67617-A497-48FB-9B63-1AAC06BD60DA@gmail.com> Date: Sun, 16 Sep 2012 14:05:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90B6D589-3A2C-42E6-9017-C9D90A3EA8A5@kientzle.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <68E67617-A497-48FB-9B63-1AAC06BD60DA@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1278) Cc: Konstantin Belousov , Eitan Adler , Adrian Chadd , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:06:00 -0000 On Sep 16, 2012, at 1:53 PM, Garrett Cooper wrote: > 2. Subversion sometimes breaks between major/minor versions (1.6->1.7 = comes to mind) and is not backwards compatible in many cases (again, 1.6 = -> 1.7 transition). Yep. The working-copy compatibility issue is a pretty serious obstacle to including SVN in base. I generally like SVN a lot, but the WC format changes are real headaches when you have a bunch of tools that use different SVN libraries.=20 Tim From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 21:16:17 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 66A9F106564A for ; Sun, 16 Sep 2012 21:16:17 +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 0BFAF14DC81; Sun, 16 Sep 2012 21:16:16 +0000 (UTC) Message-ID: <505641A0.10606@FreeBSD.org> Date: Sun, 16 Sep 2012 14:16:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warner Losh References: <201209141601.q8EG1lmf003367@fire.js.berklix.net> <2C4DFA77-E2D8-4DA1-9512-5497ADAF740E@bsdimp.com> In-Reply-To: <2C4DFA77-E2D8-4DA1-9512-5497ADAF740E@bsdimp.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Removing CVS from HEAD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:16:17 -0000 On 09/14/2012 21:39, Warner Losh wrote: > I think that we've reached the point in this thread that "no clear consensus exists for the change, therefore the status quo should remain the case." > > All these points and counter points clearly show there's non consensus, so this should be tabled. "I don't think that word means what you think it means." Consensus does not mean "absence of opposing views." It means that the weight of opinion is on one side, and the points raised by those opposed have been carefully considered; and either accommodated or discarded as less important than the benefits of the majority view. The mere fact that someone disagrees with a proposed change should not be enough on its own to scuttle that change. In this case the weight is clearly in the "remove it" camp, and the opposing opinions have been considered, and should be discarded. Defining consensus the other way only gets you the least objectionable changes, which are almost never the best by a purely technical measure. Which is not to say that we should _never_ consider other factors, merely that in a software project one would think that technical merit really should be the deciding factor in the majority of cases. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 21:46:01 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C95A106566B for ; Sun, 16 Sep 2012 21:46:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 069C88FC0A for ; Sun, 16 Sep 2012 21:46:00 +0000 (UTC) Received: by iea17 with SMTP id 17so5888362iea.13 for ; Sun, 16 Sep 2012 14:46:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=H3lVsF2lerZZ7hiKJbwM0v4WZUEH5TId4SXMBroJF5g=; b=EEX+yReKYeQ0jilsTvEJcCvRDIY3ix9c1+myoEgKn5muk/k7NxrKYWiL8Y0V68nwLP ClkCG8Pd/wgeDPRSZekydsju2SvVAqC5F3vsdK33wQKmXWbfgFBA7JZ/gQBNXwYv33PU 0N5HAwPjEvBM+X8TVdAanrWfzJMpfdvUBoZRrTctkKtm7IaJKp3jTgIuucfqE0EuEQhG 8CUyydiNf8472zy6zNIVbdRVVPt1l14BuLBCb0ozuSvGyK2cdWK8NeFElo6/hC+JxB9c MwfwyZJWKnYbXFlRpg79xyJsjME+xc5vT/1lInGPRaOdyvVdeEDNJMuLRosQwkUW2OvV vc3w== Received: by 10.50.183.135 with SMTP id em7mr5065452igc.31.1347831960231; Sun, 16 Sep 2012 14:46:00 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id 10sm13410873igf.11.2012.09.16.14.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 14:45:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50563EA6.1050908@FreeBSD.org> Date: Sun, 16 Sep 2012 15:45:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn4yylLSnGOgwg4/fj3iP379HQykV3o8jqT6XVA9Prmz6lWh1aUnTW/9RMsKVl1Qp1E/kaO Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:46:01 -0000 On Sep 16, 2012, at 3:03 PM, Doug Barton wrote: > On 09/16/2012 09:03, Warner Losh wrote: >> One of the things we are trying to move towards is that current can = be cut into a release branch on short notice. We need to keep it as = close to production ready as possible. People >=20 > I find your response here interesting Warner, given that when I have > opposed what I felt were too-drastic changes in HEAD (such as removing > sysinstall before a post-install configuration solution was ready) = your > response has been, "It's HEAD, we can break things ... let's see what > happens!" sysinstall replacement was a different discussion, with differing = technical criteria. Also, using it against me now for consistency likely isn't so good. I = think we moved too quickly, in retrospect, on that. That experience = suggests we be more cautious in the future, including for things like = this. > Now that you are the one opposed to the change, we need to > keep HEAD "close to production ready." Look at bz's push in this area. Also, I'm not opposed to this change, = just opposed to this change today, as explained elsewhere. > There is a compromise solution here that I have been hesitant to offer > because I was really hoping that sanity would prevail. But why not > switch the default MK_CVS knob over to "no" now? That will give us an > opportunity to see if there really will be any fallout, and easily fix > it if there is. I believe that's already been done. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 21:47:58 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F29651065670 for ; Sun, 16 Sep 2012 21:47:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id B15AF8FC0A for ; Sun, 16 Sep 2012 21:47:57 +0000 (UTC) Received: by iea17 with SMTP id 17so5889674iea.13 for ; Sun, 16 Sep 2012 14:47:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=O5R8860rQX9O5paJX3WBz5N6uV56N2I4dGnbXeta7Xk=; b=po5Visb9slFxQItsp1jCTEHqu/e38DgIfpuif0a6gOnPI9X99llVlD8JBdeUAG5KP+ Gfjc+jwG9KzTWqeKy73s0+l8f75QAxXNarB7wUgbmpe2bzmYCXF2NssEoImd4w/eSMO6 ii09UDwBp+d1a1IYVqMNmtFaAZay2cO752OjuHiM3leSUnqpCYXO3vTQuPF1jpxTMISc 8VbSe1biuGC7twb/PnVqGe7CvuUd17YPYSP2/gsbfzlJq0a7NDENr47pybhWrVA8wog9 fqpcB01odFwt0UunuoFCEA8nN7eyv7qw775BgzW53JbinKgbUW7/ndiXtaMk6+AmDRUm OFag== Received: by 10.50.85.134 with SMTP id h6mr4997372igz.2.1347832077040; Sun, 16 Sep 2012 14:47:57 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fm8sm13429399igc.8.2012.09.16.14.47.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 14:47:56 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <505641A0.10606@FreeBSD.org> Date: Sun, 16 Sep 2012 15:47:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209141601.q8EG1lmf003367@fire.js.berklix.net> <2C4DFA77-E2D8-4DA1-9512-5497ADAF740E@bsdimp.com> <505641A0.10606@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnZXjfrDsnbVDsrM7M7gaQfYzAZg3lcHqMh2BSsVeYIEOkR94muchTqY/YQ4uxbMq18rQJ7 Cc: arch@freebsd.org Subject: Re: Removing CVS from HEAD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:47:58 -0000 On Sep 16, 2012, at 3:16 PM, Doug Barton wrote: > On 09/14/2012 21:39, Warner Losh wrote: >> I think that we've reached the point in this thread that "no clear = consensus exists for the change, therefore the status quo should remain = the case." >>=20 >> All these points and counter points clearly show there's non = consensus, so this should be tabled. >=20 > "I don't think that word means what you think it means." >=20 > Consensus does not mean "absence of opposing views." It means that the > weight of opinion is on one side, and the points raised by those = opposed > have been carefully considered; and either accommodated or discarded = as > less important than the benefits of the majority view. The mere fact > that someone disagrees with a proposed change should not be enough on > its own to scuttle that change. >=20 > In this case the weight is clearly in the "remove it" camp, and the > opposing opinions have been considered, and should be discarded. >=20 > Defining consensus the other way only gets you the least objectionable > changes, which are almost never the best by a purely technical = measure. > Which is not to say that we should _never_ consider other factors, > merely that in a software project one would think that technical merit > really should be the deciding factor in the majority of cases. We're working towards consensus. We weren't there when I sent this out, = and it seems like the folks doing the work have agreed that a few minor = things should be completed first. Oh, and one more thing, I hope you have a nice day. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 22:59:40 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F2C1106566C for ; Sun, 16 Sep 2012 22:59:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E1EA08FC0A for ; Sun, 16 Sep 2012 22:59:39 +0000 (UTC) Received: by dadr6 with SMTP id r6so4011465dad.13 for ; Sun, 16 Sep 2012 15:59:39 -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=Axq+pMjz6WVxTf9drN14wvmgbdabWf07mnuqQ5/4q2A=; b=virOlRHjNnSucSxPJ1YOs5PyPfzsEBcBt/EwTBrrf7I+Cu/V5F5/cnMJJHPZkjiB3u Oeg6+1gfHpMm4TIZ3E8LumIBzTWPNFij0chY/QDierIdjvQEEcn+96Ywh8TYdq3WxCY+ zd3JrsTXbMpjUibl7FL5PfUl2BsGtxf5KxULTrPa/Un0N28mvJXpGCMzfB+7FpiShgQ+ JHlOd39Hra5Aj9yDxGFfOyCBn67XDw4ibuKwFObqL7rW7o55lhyrFkjGzGcvNlc+drpl 2+0itSUPqKTmPP4HGU0/aPvfeNK4ocexFjeudwnrthXEqyq0dsAizPiBGpjlfkbFEfbK ryiA== MIME-Version: 1.0 Received: by 10.68.189.164 with SMTP id gj4mr8847192pbc.48.1347836379387; Sun, 16 Sep 2012 15:59:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Sun, 16 Sep 2012 15:59:39 -0700 (PDT) In-Reply-To: References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> Date: Sun, 16 Sep 2012 15:59:39 -0700 X-Google-Sender-Auth: TTQEP15rP_neVn72USsL1zOdbqc Message-ID: From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 22:59:40 -0000 Hi, I'm not specifically saying that what _you_ are saying comes across as anti-GPL. There are more people involved in the march to "BSD everything" than you. :-) Adiran On 16 September 2012 13:07, Eitan Adler wrote: > On 16 September 2012 15:53, Adrian Chadd wrote: > >> * I'd like to first see a roadmap for doing this - eg, "we're adding a >> NO_CVS option; CVS will become a port, you can migrate to the CVS port >> with your next build/installworld"; > > We have WITHOUT_CVS . > >> * if you're that way inclined, backport the NO_CVS option (if it >> doesn't exist) to -9; > > Already done. > >> * Ensure all of the stuff that uses CVS is migrated beforehand, and >> publish all of that effort somewhere; > > This is part of my plan. > >> * Make sure you're doing it for reasons that aren't coming across as >> "GPL free! at all costs!" > > This has nothing to do with the reasons I proposed to remove CVS. > Please re-read my original email. The first words were "CVS is > obsolete." > I had *no idea* CVS was GPLed until the thread started (I thought were > using a BSD licensed one). > >> Now, to stir up trouble, I hereby suggest that if you're going to >> remove CVS because it's no longer used for FreeBSD's project stuff, we >> should obviously import subversion into the base because _it_ is being >> used for the FreeBSD project stuff. > > Please re-read the original thread. I am removing CVS because it is > obsolete. CVS being used for FreeBSD project was merely a key blocker > to its removal. > >> Think of why you're not doing that >> (likely because it's already a port/package and there's just as much >> inertia to introduce something to the base system as there is removing >> it and making it a port) and see if that helps refocus your reasons >> for and against doing things. > > I am not proposing introducing subversion into base because I am not > willing to do the work to maintain it. If I were, that would be a > different story (imho, the base should have sufficient software to > download and compile itself). > > > -- > Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 09:47:19 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 071D91065673 for ; Mon, 17 Sep 2012 09:47:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D313A8FC0C for ; Mon, 17 Sep 2012 09:47:18 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6C1EE46B17; Mon, 17 Sep 2012 05:47:18 -0400 (EDT) Date: Mon, 17 Sep 2012 10:47:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Konstantin Belousov In-Reply-To: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> Message-ID: References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:47:19 -0000 On Sun, 16 Sep 2012, Konstantin Belousov wrote: > On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: > > Removing the whole CVS discussion above, want to answer to seemingly > unrelated note in your email, which I see as continuing very disturbing > trend. > >> However, -CURRENT is not meant to be a production system. > > It is simply not true. CURRENT shall never be knowingly put into a state > where it cannot be used for the 'production-grade' use, whatever it means. > We do accept changes are so disruptive that some unknown fallout is > expected, since otherwise developers cannot make any significant progress. > > But introducing known breakage is simply not acceptable. Doing so shrinks > the already limited testing base we have for HEAD. I'd argue that one of the greatest improvements in FreeBSD development in the early 2000s was the shifting of high-risk work-in-progress development from the CVS head to Perforce. This allowed the head to remain remarkably stable during the multi-year SMPng, KSE, TrustedBSD, GEOM, etc, projects that would otherwise have been remarkably disruptive. This trend has continued with increased use of Subversion branches, Git/Mercurial repositories, etc. Many companies develop their products alongside -CURRENT branches because they need a long in-field product lifespan only accomplished by shipping based on .0 or .1 releases, or because they are jointly developing a feature with other members of the FreeBSD community. We definitely do not want to discourage carefully reasoned use of -CURRENT in products, while recognising the risks associated with an in-progress software revision. Certainly, we want to avoid bumping developers off -CURRENT, and the goal should be to keep -CURRENT maximially usable at all times -- in early FreeBSD development cycles, we saw the severe problems associated with not doing so (e.g., 3.x-era VM work that pushed many developers off -CURRENT for even personal work). Robert From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 12:37:27 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AB61065672; Mon, 17 Sep 2012 12:37:27 +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 AFEF48FC08; Mon, 17 Sep 2012 12:37:26 +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 q8HCbVYc059312; Mon, 17 Sep 2012 15:37:31 +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 q8HCbJtB037079; Mon, 17 Sep 2012 15:37:19 +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 q8HCbJ0n037078; Mon, 17 Sep 2012 15:37:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Sep 2012 15:37:19 +0300 From: Konstantin Belousov To: Andrey Zonov Message-ID: <20120917123719.GS37286@deviant.kiev.zoral.com.ua> References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <50463026.8000506@FreeBSD.org> <504653CD.2000707@FreeBSD.org> <5046F4E0.6000606@FreeBSD.org> <50561223.7060709@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Z3Qj54wC++taHdq" Content-Disposition: inline In-Reply-To: <50561223.7060709@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: [patch] unprivileged mlock(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:37:27 -0000 --/Z3Qj54wC++taHdq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 16, 2012 at 09:53:39PM +0400, Andrey Zonov wrote: > On 9/5/12 10:44 AM, Andriy Gapon wrote: > > on 04/09/2012 22:17 Andrey Zonov said the following: > >> On 9/4/12 8:45 PM, Andriy Gapon wrote: > >>> on 30/08/2012 12:06 Andrey Zonov said the following: > >>>> Hi, > >>>> > >>>> So, I've got the first version of the patch (attached) which fixes= =20 > >>>> memory locked limit checking and accounting. > >>> > >>> Andrey, > >>> > >>> your mlock.patch looks good to me, but I haven't verified pieces under > >>> RACCT. Please try to get a review from a person who is knee-deep in t= he > >>> VM code like alc or your mentor. > >>> > >> > >> Thanks for review! > >> > >>> The code should also be sent for vetoing to security@. Not sure if y= ou > >>> would get a review there, but absence of nays would be good. > >>> > >>> When the code is ready to be committed, please remember about=20 > >>> memorylocked=3Dunlimited in the default entry of the default login.co= nf. A > >>> big warning about it will have to be posted (in UPDATING and > >>> current@/stable@ at the very least). > >>> > >> > >> After that amd(8), geli(8) and watchdogd(8) will be broken, because th= ey=20 > >> call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLOCK= =2E I > >> will prepare patches for raising limits if there is no other solution. > >=20 > > Thanks for working on this. > > BTW, I am not sure why those applications would get broken... > > We could/should still have memorylocked=3Dunlimited for the 'root' clas= s. > > Or is it about something else? > >=20 >=20 > Hmm, I thought that root login class commented out. >=20 > >>> Thank you very much for doing this work. > >>> > >>> P.S. It would probably make sense to provide some HTTP home for this > >>> patch as well. > >>> > >> > >> Updated patch is here [1]. > >> > >> [1] http://people.freebsd.org/~zont/mlock1.patch > >> > >=20 > > Thank you! > > One additional thing - we probably should retire PRIV_VM_MLOCK and > > PRIV_VM_MUNLOCK. That would include making changes to > > sys/i386/ibcs2/ibcs2_misc.c and sys/ofed/drivers/infiniband/core/umem.c. > >=20 >=20 > They are useful for jails as trasz@ mentioned on IRC. >=20 > > P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder wh= at was > > the intended use for it (if any)... > >=20 >=20 > So, here is the second version of the patch [1]. >=20 > [1] http://people.freebsd.org/~zont/mlock2.patch In priv_check_cred(), s/to unprivileged/for unprivileged/. In vm_mmap(), on RLIMIT_VMEM failure, racct change shall be rolled back. I am not sure why e.g. sys_obreak() forces racct limits instead of obeing. --/Z3Qj54wC++taHdq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBXGX8ACgkQC3+MBN1Mb4jV1wCcCsv+7MaaB8EUqYJer+Hdx48z E+YAoPN1PxTSYwnFt/ae+XizRl+D97c1 =MriE -----END PGP SIGNATURE----- --/Z3Qj54wC++taHdq-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 20:19:21 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 749961065670 for ; Mon, 17 Sep 2012 20:19:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCC88FC15 for ; Mon, 17 Sep 2012 20:19:20 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8HKJJJA043820 for ; Mon, 17 Sep 2012 15:19:19 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8HKJJ8n043819 for arch@freebsd.org; Mon, 17 Sep 2012 15:19:19 -0500 (CDT) (envelope-from brooks) Date: Mon, 17 Sep 2012 15:19:19 -0500 From: Brooks Davis To: arch@freebsd.org Message-ID: <20120917201919.GA43626@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:19:21 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As part of an effort to improve our ability to create full system images without root access I would like to import NetBSD's version of mtree. By doing so we would gain the -C option which produces mtree files compatible with libarchive and makefs (one line per file with full path) and the -N option which allows a stand alone set of passwd and group files. When mated with the -U and -M options to NetBSD's install we will have most[0] of the pieces require to allow installworld to run as a user and then build images containing proper permissions. The rest of this post will focus on my plans for mtree since it is the logical next step. NetBSD's mtree is missing a few features present in our mtree. Most of them looks simple to implement and I plan to do so before any import. The only exception is -i which implements indenting of old-style mtree files to match the format of the files in /etc/mtree/. It will either need another name or to be dropped. I honestly don't see the point in it so I'm not sure if it's worth keeping if people will need to alter their scripts regardless, but I'm willing to be convinced otherwise. Importing mtree requires importing or implementing some enhancements to libc. First, the strsvis() function is required which is most easily handled by importing NetBSD's vis/unvis implementations with the addition of the VIS_GLOB set of characters. Compatibly wrappers will be required for existing vis(3) functions and for unvis() due to ABI changes, but they will be minimal. Second, pwcache_userdb(), uid_from_user(), pwcache_groupdb(), and gid_from_group() provide useful enhancements to the uid_from_user() and group_from_gid(). They appear to be entirely compatible with our current implementation so simply importing the enhanced version seems like the best course. Finally, FreeBSD and Mac OS have the functions fflagstostr() and strtofflags() in libc. NetBSD has flags_to_string() and string_to_flags() in libutil. The latter could be a very thin wrapper around fflagstostr() and the former is exactly strtofflags(). I think the best course is probably to provide compatible wrappers for mtree's internal use, but I could be convinced to make them more globally available. Does anything about this plan seem seriously objectionable? I've written some of this up along with a list of missing features in the wiki. I'll keep progress up to date there: http://wiki.freebsd.org/NetBSDMtree -- Brooks [0] We also lack a tool to build disk images including partition tables, but Marcel is looking into this. --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQV4XGXY6L6fI4GtQRAvMoAJ9niVzHRkF+5Hul8mOhM4gnzIwXwgCfUVg/ X8/O6M8IMsX+8KtbmdqgZrs= =AMp+ -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 20:52:41 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 351D21065670 for ; Mon, 17 Sep 2012 20:52:41 +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 DF2E514F9D6; Mon, 17 Sep 2012 20:52:40 +0000 (UTC) Message-ID: <50578D98.7080902@FreeBSD.org> Date: Mon, 17 Sep 2012 13:52:40 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warner Losh References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> In-Reply-To: <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:52:41 -0000 On 09/16/2012 14:45, Warner Losh wrote: > > On Sep 16, 2012, at 3:03 PM, Doug Barton wrote: > >> On 09/16/2012 09:03, Warner Losh wrote: >>> One of the things we are trying to move towards is that current can be cut into a release branch on short notice. We need to keep it as close to production ready as possible. People >> >> I find your response here interesting Warner, given that when I have >> opposed what I felt were too-drastic changes in HEAD (such as removing >> sysinstall before a post-install configuration solution was ready) your >> response has been, "It's HEAD, we can break things ... let's see what >> happens!" > > sysinstall replacement was a different discussion, with differing technical criteria. Right... in the sysinstall case we had a mainline system tool that was actively being used, with no replacement in sight. It should not have been removed until we had a viable replacement in the base. In the CVS case we have something that was _formerly_ in a similar category, but is not any longer. > Also, using it against me now for consistency likely isn't so good. I think we moved too quickly, in retrospect, on that. That experience suggests we be more cautious in the future, including for things like this. Careful! You're coming dangerously close to saying I was right about something. :) >> Now that you are the one opposed to the change, we need to >> keep HEAD "close to production ready." > > Look at bz's push in this area. Yes, I think it's awesome that someone else has finally taken up the "plz 2 stop brking teh head, kplztks" banner. Too bad it's still being ignored. > Also, I'm not opposed to this change, just opposed to this change today, as explained elsewhere. Doing it now has a lot of benefits, but ... >> There is a compromise solution here that I have been hesitant to offer >> because I was really hoping that sanity would prevail. But why not >> switch the default MK_CVS knob over to "no" now? That will give us an >> opportunity to see if there really will be any fallout, and easily fix >> it if there is. > > I believe that's already been done. It isn't now, but it sounds to me like you're saying that you're not opposed to doing so? Eitan, if you're listening, I'd strike while the iron is hot. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 21:34:03 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89CF510656EE for ; Mon, 17 Sep 2012 21:34:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49C478FC12 for ; Mon, 17 Sep 2012 21:34:03 +0000 (UTC) Received: by iea17 with SMTP id 17so7828829iea.13 for ; Mon, 17 Sep 2012 14:34:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KFfRD4GRbPTRrEExqYGvPUIizV17XsbeQTCxsnJ6L/A=; b=em90d3eJ/kAqc5061ruZWRIhlaqkMktmnzCX+OkJwErrA68cmSA9juF490Tz1JrsfW UsUGodI1H7HHLj1tkfOBzRhCDP+93n1jezK4ysGOK0wgVqURljr+R4urIHJa7DQiiLZk ULI2QLXp8IDcZ171/xEr5cmm9y2jKPcrj6X8B+bHTH+Nl5wdcZEr/tz+gIdTOQYw1SeX i+9r/HEapspWrEWJ0l6XjGe5Xi8ZBVeMgcd/38t2jnEDhiOR2F1RLUr6f6Slc1l08Q7W MIFCG0dLNWR6gZ0M+Hl0E5xZ/mPN12xAYeAbMtSkYGlF3dOmi/YnA1/Sb8fDem2q6HeC 7f4A== Received: by 10.50.158.226 with SMTP id wx2mr8308148igb.70.1347917642768; Mon, 17 Sep 2012 14:34:02 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id q1sm19686951igj.15.2012.09.17.14.33.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:34:00 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120917201919.GA43626@lor.one-eyed-alien.net> Date: Mon, 17 Sep 2012 15:33:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120917201919.GA43626@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlkK0f1YY/HKiJGLKezxUIRgPNvrognMVINBwMVI6csBZck2zrG78lZpPWvNRVZMRXt/sfs Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:34:03 -0000 On Sep 17, 2012, at 2:19 PM, Brooks Davis wrote: > As part of an effort to improve our ability to create full system = images > without root access I would like to import NetBSD's version of mtree. > By doing so we would gain the -C option which produces mtree files > compatible with libarchive and makefs (one line per file with full > path) and the -N option which allows a stand alone set of passwd and > group files. >=20 > When mated with the -U and -M options to NetBSD's install we will have > most[0] of the pieces require to allow installworld to run as a user = and > then build images containing proper permissions. The rest of this = post > will focus on my plans for mtree since it is the logical next step. >=20 > NetBSD's mtree is missing a few features present in our mtree. Most = of > them looks simple to implement and I plan to do so before any import. > The only exception is -i which implements indenting of old-style mtree > files to match the format of the files in /etc/mtree/. It will either > need another name or to be dropped. I honestly don't see the point in > it so I'm not sure if it's worth keeping if people will need to alter > their scripts regardless, but I'm willing to be convinced otherwise. >=20 > Importing mtree requires importing or implementing some enhancements = to > libc. First, the strsvis() function is required which is most > easily handled by importing NetBSD's vis/unvis implementations with = the > addition of the VIS_GLOB set of characters. Compatibly wrappers will > be required for existing vis(3) functions and for unvis() due to ABI > changes, but they will be minimal. >=20 > Second, pwcache_userdb(), uid_from_user(), pwcache_groupdb(), and > gid_from_group() provide useful enhancements to the uid_from_user() > and group_from_gid(). They appear to be entirely compatible with our > current implementation so simply importing the enhanced version seems > like the best course. >=20 > Finally, FreeBSD and Mac OS have the functions fflagstostr() and > strtofflags() in libc. NetBSD has flags_to_string() and > string_to_flags() in libutil. The latter could be a very thin wrapper > around fflagstostr() and the former is exactly strtofflags(). I think > the best course is probably to provide compatible wrappers for mtree's > internal use, but I could be convinced to make them more globally > available. >=20 > Does anything about this plan seem seriously objectionable? Looks good to me. I started doing this a while ago an ran into lots of = problems, many of which you've outlined here. They weren't hard = problems, just numerous enough for me to lose interest in the project = before I completed it. Glad to see somebody has pushed through. > I've written some of this up along with a list of missing features in > the wiki. I'll keep progress up to date there: >=20 > http://wiki.freebsd.org/NetBSDMtree >=20 > -- Brooks >=20 > [0] We also lack a tool to build disk images including partition = tables, > but Marcel is looking into this. makefs will build the disk image w/o the MBR/GPT tables. For most flash = devices, this is sufficient. For more complex situations, like where = the boot loader groks FAT but not UFS, that needs some help... Once upon = a time, you could use dd + fdisk to create an MBR image, but nothing = apart from the kernel understands using it. gpart is so darn easy to = use, it is a shame that you have to make a privileged trip to the kernel = to use it.=20 Warner= From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 21:52:26 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DCC106564A for ; Mon, 17 Sep 2012 21:52:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id C03148FC1C for ; Mon, 17 Sep 2012 21:52:25 +0000 (UTC) Received: by iea17 with SMTP id 17so7858692iea.13 for ; Mon, 17 Sep 2012 14:52:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ppGmbqHkkZYtL6+9hl2U8kcIerM96HnNTLclm3I75yU=; b=USs61fFRogJUlqwhFp8r0ALhSaeE9Y2HzQRGn8j8W8b/zwwEIAl6wc/O37mWRtPjof U5qmCT7Uv+750P6tWZGZbFzEPlyu5Lp6cOmE3SxulZY+r0SZUOdgnodhQgi5Olw/gWf1 Qurj4Qllimxh9TsnShUgExGEGUScAkKqrdbp1oSEAEF+9H8APWpkkpSemUCcVvPzLWD4 Aw5mlk2KBijyM/YYLy+2TZ3WmPdwCML59BhTCj9fPhjjAnR7lR2XOncpm+ZSSc7rmSWC W/BrlWOEntfD2I9MkGfsjQZPIxVxQsj6dxjdXHPv467rNyM2xOZcDlCpAvzexeL2oPCj 4k/g== Received: by 10.50.88.194 with SMTP id bi2mr8438121igb.47.1347918745372; Mon, 17 Sep 2012 14:52:25 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id 10sm19777642igf.11.2012.09.17.14.52.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:52:23 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50578D98.7080902@FreeBSD.org> Date: Mon, 17 Sep 2012 15:52:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmdChpzcsoyfbrA0TSH1OWwItYl2vvoSq/xB/n4/xGX1v5WY3KXO10aPZMv98GqHQUXxsSL Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:52:26 -0000 On Sep 17, 2012, at 2:52 PM, Doug Barton wrote: > On 09/16/2012 14:45, Warner Losh wrote: >>=20 >> On Sep 16, 2012, at 3:03 PM, Doug Barton wrote: >>=20 >>> On 09/16/2012 09:03, Warner Losh wrote: >>>> One of the things we are trying to move towards is that current can = be cut into a release branch on short notice. We need to keep it as = close to production ready as possible. People >>>=20 >>> I find your response here interesting Warner, given that when I have >>> opposed what I felt were too-drastic changes in HEAD (such as = removing >>> sysinstall before a post-install configuration solution was ready) = your >>> response has been, "It's HEAD, we can break things ... let's see = what >>> happens!" >>=20 >> sysinstall replacement was a different discussion, with differing = technical criteria. >=20 > Right... in the sysinstall case we had a mainline system tool that was > actively being used, with no replacement in sight. It should not have > been removed until we had a viable replacement in the base. sysinstall's primary purpose was to install the system. It was also = useful for configuration, and that auxiliary part was missing. Given the = extreme barrier to entry for the replacement, it seemed wise at the time = to let bsdinstall in without the bsdconfig part. Given the bumps we've = had in bsdinstall, I think the push to get it in was premature from the = functionality it provided at the time. We've since mostly fixed it. > In the CVS case we have something that was _formerly_ in a similar > category, but is not any longer. cvs is still being used, but not in a primary role. I want to make sure = that the transition is fully documented with the new info before we cut = cvs loose. >> Also, using it against me now for consistency likely isn't so good. = I think we moved too quickly, in retrospect, on that. That experience = suggests we be more cautious in the future, including for things like = this. >=20 > Careful! You're coming dangerously close to saying I was right about > something. :) You were right, but for the wrong reasons. :) Nah, I'll give you this = one. >>> Now that you are the one opposed to the change, we need to >>> keep HEAD "close to production ready." >>=20 >> Look at bz's push in this area.=20 >=20 > Yes, I think it's awesome that someone else has finally taken up the > "plz 2 stop brking teh head, kplztks" banner. Too bad it's still being > ignored. Lots of people say it, until they want something in the system that is = unstable... :) >> Also, I'm not opposed to this change, just opposed to this change = today, as explained elsewhere. >=20 > Doing it now has a lot of benefits, but ... >=20 >>> There is a compromise solution here that I have been hesitant to = offer >>> because I was really hoping that sanity would prevail. But why not >>> switch the default MK_CVS knob over to "no" now? That will give us = an >>> opportunity to see if there really will be any fallout, and easily = fix >>> it if there is. >>=20 >> I believe that's already been done. >=20 > It isn't now, but it sounds to me like you're saying that you're not > opposed to doing so? MK_CVS moving to 'no' by default is something we can do right away, = since it is easy to figure out what went wrong for the people using cvs = and putting it back w/o needing to download anything new. Living behind = firewalls can make downloads a pita. I have had systems with very = specific holes that made it a PITA to download anything to them, and it = is a common occurrence. > Eitan, if you're listening, I'd strike while the iron is hot. :) Since I thought that had already been done, please do so. Please make = sure that ObsoleteFiles does the right thing too :) Oh, and make sure = UPDATING is updated. Warner= From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 22:03:55 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FD1A1065672 for ; Mon, 17 Sep 2012 22:03:55 +0000 (UTC) (envelope-from lists@eitanadler.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 134548FC1E for ; Mon, 17 Sep 2012 22:03:54 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so10532586pbb.13 for ; Mon, 17 Sep 2012 15:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0ATvNQACMzqKEyniDU1aNrxKFJ5/N/6g0sDJH4szGC0=; b=FZwSO5rttpQL8LrCxq8zwtb+C9dA8Ds9H29ajtr/B0FnoTK1tQ4tHhpWt1LeV8Cqdy +uD2WWgq15GbQy7F2J/I/LLfxZbJbNDKtGkRcEKg8oyIaRdHgNeXHjYHRq445zi0XvN/ mu4UoA0Wffd66tICP34lsZuFF2qQKgrMsogfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=0ATvNQACMzqKEyniDU1aNrxKFJ5/N/6g0sDJH4szGC0=; b=XgQjvzPcS9Wrk6j3K7PU+G5S0cFBnQTY4N1NC0Jp6rAuPWMgWjEKV+dqQmJeSvb3ux TL0FkLLmDsrXEhv96/SJPQvHHTWmQm86yOubb2LUAfhoiJsbN/8FYf057GAWOqmbGMfr Ovtd3FlHhVNKc6tIs9zpvyeIbmNcD3lYdG/WIh+PMYQhdnii7dUM6RmMfhKM7cwtIna8 ve7Po7FVXSU9DvkCyhIqNYx1k7a848PPIzJ081318CAmdhhT5XLSjFbZC8pXNu4kFRpa xXEND35ih6Vih/c0oTR3FRIqKXB2xC/ov+hBZLYsdWfx8J0qZnhZDDDrsrwj+pG+6m0y KtBA== Received: by 10.68.130.65 with SMTP id oc1mr24591873pbb.29.1347919434688; Mon, 17 Sep 2012 15:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.41 with HTTP; Mon, 17 Sep 2012 15:03:24 -0700 (PDT) In-Reply-To: <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org> <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> From: Eitan Adler Date: Mon, 17 Sep 2012 18:03:24 -0400 Message-ID: To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlSazo2aNpV/eMcyvN4JQcLJrFYP/YqDEKcO+LXGuZ8Dxl/Os5hNB8gONGhDHPE2JjbURBC Cc: Konstantin Belousov , arch@freebsd.org, Doug Barton Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:03:55 -0000 On 17 September 2012 17:52, Warner Losh wrote: [snip] >>>> There is a compromise solution here that I have been hesitant to offer >>>> because I was really hoping that sanity would prevail. But why not >>>> switch the default MK_CVS knob over to "no" now? That will give us an >>>> opportunity to see if there really will be any fallout, and easily fix >>>> it if there is. >>> >>> I believe that's already been done. >> >> It isn't now, but it sounds to me like you're saying that you're not >> opposed to doing so? > > MK_CVS moving to 'no' by default is something we can do right away, since= it is easy to figure out what went wrong for the people using cvs and putt= ing it back w/o needing to download anything new. Living behind firewalls = can make downloads a pita. I have had systems with very specific holes tha= t made it a PITA to download anything to them, and it is a common occurrenc= e. > >> Eitan, if you're listening, I'd strike while the iron is hot. :) > > Since I thought that had already been done, please do so. Please make su= re that ObsoleteFiles does the right thing too :) Oh, and make sure UPDATI= NG is updated. I have some surrounding commits to get done first. I'd like to get some of the existing documentation that refers to CVS removed or modified first. There is some consensus for making MK_CVS default to "no" early, so I'll take that into account and commit that sooner than the above listed conditions. Does this change require a OSVERSION bump? I'm inclined to say yes as the ports infrastructure might need to be aware of the change. --=20 Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 23:01:10 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86628106564A for ; Mon, 17 Sep 2012 23:01:10 +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 572F98FC16 for ; Mon, 17 Sep 2012 23:01:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so10613401pbb.13 for ; Mon, 17 Sep 2012 16:01:09 -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 :content-transfer-encoding; bh=cyD9G3F/n40bvQGXTGEkOvQdLD4Vgf4rAQ4U9MsIRJ4=; b=ZVSpNf5iDUIVOEBdRN4BOypvTEhuSDJxnI1ZhkFo6mhP9D7jug1/XUMzix7p7oDYaY 9XYNjXkirziqrfREP5MlNFoIRsSChVepJiWiaGyKyngCyZ+jlXOGeV7jyFxGIQTxJjwG UF4FmfSo795pJ/9sDXRMH6sQghiGyr44wI+JRvLtEIBalllBTe5B2/3MZLO6RX3mkQQ0 JljYQ4PdSCcVt1g3ZnniCPdOiFYPHCHmnKYpm3tpSIJGJORzGgV+4R8ntmQmNGoMgOKn yEnZ1f4lf4PakneXg4oGusB+JReZEdX3RJVsiHOLFIQGCPYtcO7NuubFj8L8g9jxC9p6 m/Cg== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr25004041pbb.27.1347922869488; Mon, 17 Sep 2012 16:01:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Mon, 17 Sep 2012 16:01:09 -0700 (PDT) In-Reply-To: References: <20120917201919.GA43626@lor.one-eyed-alien.net> Date: Mon, 17 Sep 2012 16:01:09 -0700 X-Google-Sender-Auth: SXb0JG4Z0i-SqTtj44w5wjMQlmY Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:01:10 -0000 It surely would be nice to be able to compile/run geom modules in userland. Just saying. :) Adrian On 17 September 2012 14:33, Warner Losh wrote: > > On Sep 17, 2012, at 2:19 PM, Brooks Davis wrote: > >> As part of an effort to improve our ability to create full system images >> without root access I would like to import NetBSD's version of mtree. >> By doing so we would gain the -C option which produces mtree files >> compatible with libarchive and makefs (one line per file with full >> path) and the -N option which allows a stand alone set of passwd and >> group files. >> >> When mated with the -U and -M options to NetBSD's install we will have >> most[0] of the pieces require to allow installworld to run as a user and >> then build images containing proper permissions. The rest of this post >> will focus on my plans for mtree since it is the logical next step. >> >> NetBSD's mtree is missing a few features present in our mtree. Most of >> them looks simple to implement and I plan to do so before any import. >> The only exception is -i which implements indenting of old-style mtree >> files to match the format of the files in /etc/mtree/. It will either >> need another name or to be dropped. I honestly don't see the point in >> it so I'm not sure if it's worth keeping if people will need to alter >> their scripts regardless, but I'm willing to be convinced otherwise. >> >> Importing mtree requires importing or implementing some enhancements to >> libc. First, the strsvis() function is required which is most >> easily handled by importing NetBSD's vis/unvis implementations with the >> addition of the VIS_GLOB set of characters. Compatibly wrappers will >> be required for existing vis(3) functions and for unvis() due to ABI >> changes, but they will be minimal. >> >> Second, pwcache_userdb(), uid_from_user(), pwcache_groupdb(), and >> gid_from_group() provide useful enhancements to the uid_from_user() >> and group_from_gid(). They appear to be entirely compatible with our >> current implementation so simply importing the enhanced version seems >> like the best course. >> >> Finally, FreeBSD and Mac OS have the functions fflagstostr() and >> strtofflags() in libc. NetBSD has flags_to_string() and >> string_to_flags() in libutil. The latter could be a very thin wrapper >> around fflagstostr() and the former is exactly strtofflags(). I think >> the best course is probably to provide compatible wrappers for mtree's >> internal use, but I could be convinced to make them more globally >> available. >> >> Does anything about this plan seem seriously objectionable? > > Looks good to me. I started doing this a while ago an ran into lots of p= roblems, many of which you've outlined here. They weren't hard problems, ju= st numerous enough for me to lose interest in the project before I complete= d it. Glad to see somebody has pushed through. > >> I've written some of this up along with a list of missing features in >> the wiki. I'll keep progress up to date there: >> >> http://wiki.freebsd.org/NetBSDMtree >> >> -- Brooks >> >> [0] We also lack a tool to build disk images including partition tables, >> but Marcel is looking into this. > > makefs will build the disk image w/o the MBR/GPT tables. For most flash = devices, this is sufficient. For more complex situations, like where the b= oot loader groks FAT but not UFS, that needs some help... Once upon a time,= you could use dd + fdisk to create an MBR image, but nothing apart from th= e kernel understands using it. gpart is so darn easy to use, it is a shame= that you have to make a privileged trip to the kernel to use it. > > Warner_______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 05:30:11 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2FDB106566C for ; Tue, 18 Sep 2012 05:30:11 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5FAC08FC1A for ; Tue, 18 Sep 2012 05:30:11 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D3C643B5A5; Tue, 18 Sep 2012 05:30:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8I5U98s065918; Tue, 18 Sep 2012 05:30:09 GMT (envelope-from phk@phk.freebsd.dk) To: Brooks Davis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 17 Sep 2012 15:19:19 EST." <20120917201919.GA43626@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 05:30:09 +0000 Message-ID: <65917.1347946209@critter.freebsd.dk> Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 05:30:11 -0000 In message <20120917201919.GA43626@lor.one-eyed-alien.net>, Brooks Davis writes : >As part of an effort to improve our ability to create full system images >without root access I would like to import NetBSD's version of mtree. >By doing so we would gain the -C option which produces mtree files >compatible with libarchive and makefs (one line per file with full >path) and the -N option which allows a stand alone set of passwd and >group files. Please make sure we don't loose the -f -f comparison option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 11:06:47 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54585106567B; Tue, 18 Sep 2012 11:06:47 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 10FA18FC14; Tue, 18 Sep 2012 11:06:46 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 808966B4E; Tue, 18 Sep 2012 13:06:40 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 2C3FD834D; Tue, 18 Sep 2012 13:06:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> Date: Tue, 18 Sep 2012 13:06:39 +0200 In-Reply-To: (Adrian Chadd's message of "Sun, 16 Sep 2012 12:53:25 -0700") Message-ID: <86fw6fa8u8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:06:47 -0000 Adrian Chadd writes: > Now, to stir up trouble, I hereby suggest that if you're going to > remove CVS because it's no longer used for FreeBSD's project stuff, we > should obviously import subversion into the base because _it_ is being > used for the FreeBSD project stuff. Importing Subversion into base has never been on the table and will never be on the table. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 12:59:24 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D712106564A for ; Tue, 18 Sep 2012 12:59:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0D10C8FC0A for ; Tue, 18 Sep 2012 12:59:23 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F21923B79D for ; Tue, 18 Sep 2012 12:59:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8ICxKiY095609 for ; Tue, 18 Sep 2012 12:59:21 GMT (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 12:59:20 +0000 Message-ID: <95608.1347973160@critter.freebsd.dk> Cc: Subject: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:59:24 -0000 In Varnish I have adopted and today I saw a weird issue on a PPC64 platform, which makes me wonder if we have a potential aliasing issue with TAILQs. The backwards pointers in TAILQs point to the forward pointer of the previous element, rather than to the top of the previous element. To go backwards you therefore have to go two steps backwards and one step forward. TAILQ_PREV and TAILQ_LAST do this by assuming that the head and element structures for a TAILQ are the same, and casts the point from &(elem->next) to &head, and dereferences head->last as a proxy for elem->prev. This is elegant, but not type-safe. I have not 100% confirmed, that in the in problem we had with PPC64, the compiler in this case fails to spot the aliasing. When I made the head-struct volatile, the problem went away, which it also did when I put in a function call at the suspect place to force a register spill. I have previously tried to find a way to rewrite TAILQ_LAST/PREV to be type-safe, but utterly failed, and I have reached the conclusion that with the current "API" or minor modifications thereof, that is patently impossible. It may be a good idea to find some way to make sure the compiler spots the potential aliasing, but I am not sufficiently up to date on compiler optimizations to know a safe and reliable way to do that. (Would explicitly casting throuh a void do it ?) Poul-Henning Details: https://github.com/varnish/Varnish-Cache/blob/3.0/bin/varnishd/cache_ban.c lines 388-393. The problem happens on startup, when the ban_head list is empty, and I belive the issue is that the (V)TAILQ_INSERT_HEAD() has not stored the head->last pointer, by the time the (V)TAILQ_LAST() tries to dereference it, and that the compiler does not spot the aliasing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 13:36:04 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01A7F106566C for ; Tue, 18 Sep 2012 13:36:04 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6DF8FC15 for ; Tue, 18 Sep 2012 13:36:02 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8IDa1aY050329; Tue, 18 Sep 2012 08:36:01 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8IDa1tg050328; Tue, 18 Sep 2012 08:36:01 -0500 (CDT) (envelope-from brooks) Date: Tue, 18 Sep 2012 08:36:01 -0500 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20120918133601.GA74177@lor.one-eyed-alien.net> References: <20120917201919.GA43626@lor.one-eyed-alien.net> <65917.1347946209@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <65917.1347946209@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:36:04 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2012 at 05:30:09AM +0000, Poul-Henning Kamp wrote: > In message <20120917201919.GA43626@lor.one-eyed-alien.net>, Brooks Davis = writes > : >=20 > >As part of an effort to improve our ability to create full system images > >without root access I would like to import NetBSD's version of mtree. > >By doing so we would gain the -C option which produces mtree files > >compatible with libarchive and makefs (one line per file with full > >path) and the -N option which allows a stand alone set of passwd and > >group files. >=20 > Please make sure we don't loose the -f -f comparison option. Added to my list of features to port. Thanks, Brooks --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQWHjAXY6L6fI4GtQRAlTrAKC4zSMSDQii+/33w7Duapr68vVYAgCdGoYq VhkuRqHwweDFQFglzEVSAuQ= =mvpp -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 15:44:10 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31DE21065673 for ; Tue, 18 Sep 2012 15:44:10 +0000 (UTC) (envelope-from asmrookie@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 A5E138FC0C for ; Tue, 18 Sep 2012 15:44:09 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so132505lbb.13 for ; Tue, 18 Sep 2012 08:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TdqfaalkL2suRX6Q3RymfxaFTOECdCCoGAFkiU3/kp0=; b=Pvia/RmTF6FoMGXFIZLSNBS82AXCrT13RNiPZ+6BLG9OEwwXsuWqzKCtJoPhBM8FzR JwrcRw0L/XtiI9qJcJAn9upvZT/YxL2HItYT2mx3Nt6GopYd35UsVpN60mJ1IuyGbgvC H6jGpRH+jC3wA+kuIo6RNCyNXkyG5e+9R3hCEADAAkvdgnuc6ws2JVRzpbS4oocTzeLi C1+sKFgCgiJ+ZorL9kPy3lWUzuHNlbx3GhLR3TQhpMWQ//N5YvtFk8qKC2Hklilrfubd V19lwE7bQj+Z6A8n4auU0PHIjp1B5aP5bHBfU6zYk6qNAjQm6tT/Rt9AfUGIzlsjev2N zwnA== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr67464lbh.85.1347983048248; Tue, 18 Sep 2012 08:44:08 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Tue, 18 Sep 2012 08:44:08 -0700 (PDT) In-Reply-To: <95608.1347973160@critter.freebsd.dk> References: <95608.1347973160@critter.freebsd.dk> Date: Tue, 18 Sep 2012 16:44:08 +0100 X-Google-Sender-Auth: PUYKh0CrEgM-lbOY3MS-h1ix4DU Message-ID: From: Attilio Rao To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:44:10 -0000 On 9/18/12, Poul-Henning Kamp wrote: > > In Varnish I have adopted and today I saw a weird issue > on a PPC64 platform, which makes me wonder if we have a potential > aliasing issue with TAILQs. I think that our queue.h (and then TAILQs too) are not guaranteed at all to be SMP safe from a CPU perspective. More importantly, being macros makes them very subjective to also compiler reordering and optimization, and this is perfectly fine. The only way I can see this code is safe is, infact, to lock it with proper locks around the operations. Even having control over the whole operation is impossible without rewriting accordingly the TAILQ operations directly to take into account memory models. If you want a lock-less implementation of TAILQs I'm afraid you need to work on your own one, using hw memory barriers where needed. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 15:53:18 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F12FB106566C; Tue, 18 Sep 2012 15:53:17 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A918A8FC12; Tue, 18 Sep 2012 15:53:17 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E29653B755; Tue, 18 Sep 2012 15:53:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IFr9ei022287; Tue, 18 Sep 2012 15:53:09 GMT (envelope-from phk@phk.freebsd.dk) To: attilio@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 16:44:08 +0100." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 15:53:09 +0000 Message-ID: <22286.1347983589@critter.freebsd.dk> Cc: arch@FreeBSD.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:53:18 -0000 In message , Attilio Rao writes: >The only way I can see this >code is safe is, infact, to lock it with proper locks around the >operations. This is not about locking: at the time where this croaks there is only one thread. The problem is that: // Empty, freshly initialized ban_head b = valid_ban_object(); TAILQ_INSERT_HEAD(&ban_head, b, list); be = TAILQ_LAST(&ban_head, banhead_s); Causes a sig#11 in TAILQ_LAST(). I belive it is a NULL dereference, and I belive it happens because the compiler overoptimizes TAILQ_{LAST|PREV}() -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:01:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32B071065780 for ; Tue, 18 Sep 2012 16:01:09 +0000 (UTC) (envelope-from asmrookie@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 A2FD38FC0C for ; Tue, 18 Sep 2012 16:01:08 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so149679lbb.13 for ; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P/I22AwwMhUappU8VsxYUjL18bbS6NrmfApn1ILpwnw=; b=Bk26kGVOhgQwkY3M3gx4yw7Wmkip3hCDzr4AomiJgZGKou8S6+cWvadjom2mQNkpYk 1kEKtmXeOF3lwgut+W54DnN3DBS0COe5uoU68sJ2nsMAgka8FAEsDLI3BqOzaGRjPStX fNe2i9hanXUfhmU8XHtiYImBjc0moPw+MkUg2L7+T8DOcZfcp/o3c06XFE0IBXizDmTe lsJAolU5fc3Oj7cAzWJOIkW6Zl+OM7MnOE37lpK9+u0I5Fl3esYtRjzwJB+7wDBpXX41 mGQyj1iKrPtQSyV5ebjF8vrK0Wiw7OQViujy2CVvKcow4jZ87x19XtBUiqtkyg3+0ADs O6fA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr203174lab.40.1347984067226; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) In-Reply-To: <22286.1347983589@critter.freebsd.dk> References: <22286.1347983589@critter.freebsd.dk> Date: Tue, 18 Sep 2012 17:01:07 +0100 X-Google-Sender-Auth: naMaBNigq_R0ujvTxQAT5n_M_Ik Message-ID: From: Attilio Rao To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:01:09 -0000 On 9/18/12, Poul-Henning Kamp wrote: > In message > > , Attilio Rao writes: > >>The only way I can see this >>code is safe is, infact, to lock it with proper locks around the >>operations. > > This is not about locking: at the time where this croaks there is > only one thread. > > The problem is that: > > // Empty, freshly initialized ban_head > > b = valid_ban_object(); > TAILQ_INSERT_HEAD(&ban_head, b, list); > > be = TAILQ_LAST(&ban_head, banhead_s); > > Causes a sig#11 in TAILQ_LAST(). > > I belive it is a NULL dereference, and I belive it happens > because the compiler overoptimizes TAILQ_{LAST|PREV}() Yep, it likely means you need to use compiler memory barriers then. I didn't look into details the implementation of TAILQ (but I can if you want) to point you precisely where, but it seems you already know that code well enough to tell where. Compiler memory barriers will avoid the compiler to reorder loads/stores before/after it and currently we use the gcc idiom for it __asm __volatile (" " : : : "memory") which forces a registers reflush. This also avoids the compiler to optimize some variables in the registers when traversing a barrier, saving the usage of "volatile" more often. TAILQ is certainly subjective to aliasing because it is inlined code, so, differently from hard functions which are safe with gcc compiling flags. However, please note that this type of issue is not only related to ppc64, but to all gcc/clang supported platforms. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:04:51 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1368C106566C; Tue, 18 Sep 2012 16:04:51 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C396F8FC12; Tue, 18 Sep 2012 16:04:50 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C682E3B75F; Tue, 18 Sep 2012 16:04:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IG4neE022352; Tue, 18 Sep 2012 16:04:49 GMT (envelope-from phk@phk.freebsd.dk) To: attilio@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 17:01:07 +0100." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 16:04:49 +0000 Message-ID: <22351.1347984289@critter.freebsd.dk> Cc: arch@FreeBSD.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:04:51 -0000 In message , Attilio Rao writes: >Yep, it likely means you need to use compiler memory barriers then. >I didn't look into details the implementation of TAILQ (but I can if >you want) Yes, It might be helpful if you knew what you were talking about, rather than shoot from the hip :-) > to point you precisely where, but it seems you already know >that code well enough to tell where. I know perfectly well where to insert the memory barrier. My point is that I don't think many people amongst our users would realize that you _need_ memory barriers when you need TAILQ's and I don't think I know of a single instance in our source tree that does... >TAILQ is certainly subjective to aliasing because it is inlined code, It's not inlining that makes it subject to aliasing, it's the casting. Please RTFC. >However, please note that this type of issue is not only related to >ppc64, but to all gcc/clang supported platforms. Which is very much why I bloody raise it on arch@ in the first place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:10:46 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B27A106566B for ; Tue, 18 Sep 2012 16:10:46 +0000 (UTC) (envelope-from asmrookie@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 7BBA28FC08 for ; Tue, 18 Sep 2012 16:10:45 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so159640lbb.13 for ; Tue, 18 Sep 2012 09:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Zyz7QuuzCBactgaju/J/ZDF3m/gOCfHQh/lgE1gsF9s=; b=w4WSEeVR+Wxlg/mw48VNWdYGGzbDAWNB5Hd1XHM522a+sMtbgwYp4ai+28+TphsCXK PQzsKfhYHicu9OSVfEmQLoXUQJ3pnnpQizSDTLnfjcrlLAD3Fim3oBwOGIe2g8G/xuUl 1LULZA73m8H//Y7prfjvRQnMwZoMkZVz5F3G4t5VKoIacMMYn8/cXViidJxMHk111wsi kKPo6ixZKVYmXWWQ7kgxcb1amgW55btqVtmhlpQ9nzgk82mdvlunfiMGIG4a0xN3Y6k3 PrjMSdDMua3rKTjt6BC4nhS465+oL6G6MBlM5K1HDFf7K3HoOj2gUSY1Jwhz2ZlHsK8z upPw== MIME-Version: 1.0 Received: by 10.152.148.162 with SMTP id tt2mr299833lab.10.1347984644133; Tue, 18 Sep 2012 09:10:44 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Tue, 18 Sep 2012 09:10:44 -0700 (PDT) In-Reply-To: <22351.1347984289@critter.freebsd.dk> References: <22351.1347984289@critter.freebsd.dk> Date: Tue, 18 Sep 2012 17:10:44 +0100 X-Google-Sender-Auth: mJmd-o-M-CboIeKWaFr-ipxpw0M Message-ID: From: Attilio Rao To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:10:46 -0000 On 9/18/12, Poul-Henning Kamp wrote: > In message > > , Attilio Rao writes: > >>Yep, it likely means you need to use compiler memory barriers then. >>I didn't look into details the implementation of TAILQ (but I can if >>you want) > > Yes, It might be helpful if you knew what you were talking about, > rather than shoot from the hip :-) > >> to point you precisely where, but it seems you already know >>that code well enough to tell where. > > I know perfectly well where to insert the memory barrier. I'm not going to reply anymore to this thread, but if you don't understand what I'm saying please stop sending stupid responses like this one. I'm obviously saying to patch *TAILQ* to take into account the possibility of compiler reordering, which has nothing to do with users knowledge of the primitive. > > My point is that I don't think many people amongst our users > would realize that you _need_ memory barriers when you need > TAILQ's and I don't think I know of a single instance in our > source tree that does... > >>TAILQ is certainly subjective to aliasing because it is inlined code, > > It's not inlining that makes it subject to aliasing, it's the casting. > > Please RTFC. What I'm saying is that there could be compiler reordering also *among* several TAILQ operations because they are inlined functions, not only *within* them. Stop acting like the old teacher speaking to stupid students. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:12:57 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4B1D106566C; Tue, 18 Sep 2012 16:12:57 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9A38FC0A; Tue, 18 Sep 2012 16:12:57 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4889E3B754; Tue, 18 Sep 2012 16:12:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IGCuh0022398; Tue, 18 Sep 2012 16:12:56 GMT (envelope-from phk@phk.freebsd.dk) To: attilio@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 17:10:44 +0100." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 16:12:56 +0000 Message-ID: <22397.1347984776@critter.freebsd.dk> Cc: arch@FreeBSD.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:12:57 -0000 In message , Attilio Rao writes: >Stop acting like the old teacher speaking to stupid students. A very apt metaphor in this case. Adding memory barriers to the TAILQ macros is not something I would do lightly, but it is, obviously, one of the possibilties. I'd far prefer if we could get away with sticking a couple of volatile's in there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:48:37 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC0F106564A; Tue, 18 Sep 2012 16:48:37 +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 2F57A8FC08; Tue, 18 Sep 2012 16:48:36 +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 q8IGmc2E029008; Tue, 18 Sep 2012 19:48:38 +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 q8IGmQan036090; Tue, 18 Sep 2012 19:48:26 +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 q8IGmQ9T036089; Tue, 18 Sep 2012 19:48:26 +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: Tue, 18 Sep 2012 19:48:26 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Message-ID: <20120918164826.GI37286@deviant.kiev.zoral.com.ua> References: <22397.1347984776@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2o2UGh95w7MMZdf3" Content-Disposition: inline In-Reply-To: <22397.1347984776@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) 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: attilio@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:48:37 -0000 --2o2UGh95w7MMZdf3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2012 at 04:12:56PM +0000, Poul-Henning Kamp wrote: > In message > , Attilio Rao writes: >=20 > >Stop acting like the old teacher speaking to stupid students. >=20 > A very apt metaphor in this case. >=20 > Adding memory barriers to the TAILQ macros is not something I would > do lightly, but it is, obviously, one of the possibilties. >=20 > I'd far prefer if we could get away with sticking a couple of > volatile's in there. Note that if the issue is with aliasing then barriers has nothing to do with the fix. In your case it is supposedly cached access from the other pointer which causes the problem, compiler must not reorder accesses which provably causes change in the behaviour. --2o2UGh95w7MMZdf3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBYpdkACgkQC3+MBN1Mb4hfkACfSJiyq65ga0vWGK/WMLQfOxAP oNwAnjtBv9BEBxNpsWgudDgJWR0PjnrN =EE2m -----END PGP SIGNATURE----- --2o2UGh95w7MMZdf3-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 17:03:23 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19C661065672; Tue, 18 Sep 2012 17:03:23 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C86AB8FC14; Tue, 18 Sep 2012 17:03:22 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8D90A3B74B; Tue, 18 Sep 2012 17:03:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IH3LuT022550; Tue, 18 Sep 2012 17:03:21 GMT (envelope-from phk@phk.freebsd.dk) To: Konstantin Belousov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 19:48:26 +0300." <20120918164826.GI37286@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 17:03:21 +0000 Message-ID: <22549.1347987801@critter.freebsd.dk> Cc: attilio@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:03:23 -0000 In message <20120918164826.GI37286@deviant.kiev.zoral.com.ua>, Konstantin Belou sov writes: >[...] compiler must not reorder accesses which >provably causes change in the behaviour. As I said, I'm not entirely sure why this goes wrong, and I didn't feel like learning PPC64 assembler constraints just now to find out. My understanding is that the cast from entry->head effectively obscures from the compiler what goes on in this case, making that optimization fair game. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 18:07:12 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9134C106564A; Tue, 18 Sep 2012 18:07:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 652FA8FC17; Tue, 18 Sep 2012 18:07:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BB84BB980; Tue, 18 Sep 2012 14:07:11 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 18 Sep 2012 13:59:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <22549.1347987801@critter.freebsd.dk> In-Reply-To: <22549.1347987801@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209181359.37965.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Sep 2012 14:07:11 -0400 (EDT) Cc: Konstantin Belousov , attilio@freebsd.org, Poul-Henning Kamp , arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:07:12 -0000 On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: > In message <20120918164826.GI37286@deviant.kiev.zoral.com.ua>, Konstantin Belou > sov writes: > > >[...] compiler must not reorder accesses which > >provably causes change in the behaviour. > > As I said, I'm not entirely sure why this goes wrong, and I didn't > feel like learning PPC64 assembler constraints just now to find out. > > My understanding is that the cast from entry->head effectively > obscures from the compiler what goes on in this case, making that > optimization fair game. Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build (assuming you had built with -O2 or higher)? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 18:07:12 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9134C106564A; Tue, 18 Sep 2012 18:07:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 652FA8FC17; Tue, 18 Sep 2012 18:07:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BB84BB980; Tue, 18 Sep 2012 14:07:11 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 18 Sep 2012 13:59:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <22549.1347987801@critter.freebsd.dk> In-Reply-To: <22549.1347987801@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209181359.37965.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Sep 2012 14:07:11 -0400 (EDT) Cc: Konstantin Belousov , attilio@freebsd.org, Poul-Henning Kamp , arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:07:12 -0000 On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: > In message <20120918164826.GI37286@deviant.kiev.zoral.com.ua>, Konstantin Belou > sov writes: > > >[...] compiler must not reorder accesses which > >provably causes change in the behaviour. > > As I said, I'm not entirely sure why this goes wrong, and I didn't > feel like learning PPC64 assembler constraints just now to find out. > > My understanding is that the cast from entry->head effectively > obscures from the compiler what goes on in this case, making that > optimization fair game. Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build (assuming you had built with -O2 or higher)? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 18:24:31 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 421DD1065670; Tue, 18 Sep 2012 18:24:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EDC848FC0C; Tue, 18 Sep 2012 18:24:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5ED273B74F; Tue, 18 Sep 2012 18:24:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IIOSKp022852; Tue, 18 Sep 2012 18:24:29 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 13:59:37 -0400." <201209181359.37965.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 18:24:28 +0000 Message-ID: <22851.1347992668@critter.freebsd.dk> Cc: Konstantin Belousov , attilio@freebsd.org, arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:24:31 -0000 In message <201209181359.37965.jhb@freebsd.org>, John Baldwin writes: >On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: >Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build >(assuming you had built with -O2 or higher)? I tried that, but it did not seem to make a difference. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 18:24:31 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 421DD1065670; Tue, 18 Sep 2012 18:24:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EDC848FC0C; Tue, 18 Sep 2012 18:24:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5ED273B74F; Tue, 18 Sep 2012 18:24:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IIOSKp022852; Tue, 18 Sep 2012 18:24:29 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 13:59:37 -0400." <201209181359.37965.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 18:24:28 +0000 Message-ID: <22851.1347992668@critter.freebsd.dk> Cc: Konstantin Belousov , attilio@freebsd.org, arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:24:31 -0000 In message <201209181359.37965.jhb@freebsd.org>, John Baldwin writes: >On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: >Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build >(assuming you had built with -O2 or higher)? I tried that, but it did not seem to make a difference. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 19:01:10 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02950106566B for ; Tue, 18 Sep 2012 19:01:10 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF38E8FC08 for ; Tue, 18 Sep 2012 19:01:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so724154pbb.13 for ; Tue, 18 Sep 2012 12:01:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=F5wN393QzZRxNruU2aD3SiXFD8dSUFTqKs883tnyPCI=; b=hupf2KN8f6BxydDDRtsZBwMB+JDxxzas7ra/e3xL/pPiAhRKoNhQx/GpYHzMtY84aV A1esC40XYu2yUZSZ3XGBX0iK8FPydz9Hry6Z1kTnFnhdDAN5naJ5hjCsa6CDPEIHnQlj ASAmgU5JfgWKDwglWstK+EDbSOwNmUmcHRAjjtDBbq3FSlv5CXamqh8cY5Q2wMbb7/68 OEWXUBGRosLe2RlQLb8Z/Qokc/gTK2B4Y67eEFjc8Ogw6oF9TkmMP7eK5ysh4UncRa2y OBDP6ttjGRocMcdKsBCXgmegH0vGh0HANM3q+Qw4P23IhSIK9dCW9c0V87G6Ne9zn1vI RnDw== Received: by 10.68.239.135 with SMTP id vs7mr1211429pbc.38.1347994869294; Tue, 18 Sep 2012 12:01:09 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id py9sm401310pbb.20.2012.09.18.12.01.07 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 12:01:08 -0700 (PDT) Date: Tue, 18 Sep 2012 09:00:38 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <22851.1347992668@critter.freebsd.dk> Message-ID: References: <22851.1347992668@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlXweOyInB1TNpZrFa4Bq2dL6GdPZYNjm0uvulzIowYqJKk2IZea8A+1PZX0zw5Nei/38Az Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 19:01:10 -0000 On Tue, 18 Sep 2012, Poul-Henning Kamp wrote: > In message <201209181359.37965.jhb@freebsd.org>, John Baldwin writes: >> On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: > >> Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build >> (assuming you had built with -O2 or higher)? > > I tried that, but it did not seem to make a difference. If you compile at low optimization levels I assume it goes away? Can you place asm volatile ("" ::: "memory"); between the two tailq macros with the same optimization level? This should prevent gcc from caching anything in registers regardless of the optimization level and would tell us if it's doing something bad. Thanks, Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 19:01:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 497AF1065678 for ; Tue, 18 Sep 2012 19:01:10 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF4758FC0C for ; Tue, 18 Sep 2012 19:01:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so724155pbb.13 for ; Tue, 18 Sep 2012 12:01:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=F5wN393QzZRxNruU2aD3SiXFD8dSUFTqKs883tnyPCI=; b=KnjARr2eAZEUolHsVOrY2ZV+OcHvdcVvdrkBhcfFMW4r80/02CJuuUXaPsDCUbI6kc zKy2EeZPXii66fucWtmsE2FreIOYgzglddv/rco0r/fdi9/3Fj4Wa2iXqvExdONuyOyM KNtN11ayMifUD5GF+PD431o0WUW46GOqb9gYxtm50UqPc8M0u6tyTQPStuk1UKj/DHuJ 1OnazDFUsWFPxxK2zj3hQTEunAl5SnSogFz62bHKAz9UF6OddR45bX7laRTfyHlR5OyG Ke/0PoRyGpSjw8RLY/bPQK4cbFzqWYGDhm+Yer8NktQ4nfzhg8l3np4dul+McvNCC4HX Zw0Q== Received: by 10.68.239.135 with SMTP id vs7mr1211429pbc.38.1347994869294; Tue, 18 Sep 2012 12:01:09 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id py9sm401310pbb.20.2012.09.18.12.01.07 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 12:01:08 -0700 (PDT) Date: Tue, 18 Sep 2012 09:00:38 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <22851.1347992668@critter.freebsd.dk> Message-ID: References: <22851.1347992668@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQmpGWTuQx5kCGPzLP9bGfAjsVh3UWrRg7Cv4vUJxrS7q3cpF4WZYpuGjrNl3FIPwL7Qc065 Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 19:01:10 -0000 On Tue, 18 Sep 2012, Poul-Henning Kamp wrote: > In message <201209181359.37965.jhb@freebsd.org>, John Baldwin writes: >> On Tuesday, September 18, 2012 1:03:21 pm Poul-Henning Kamp wrote: > >> Did you have -fno-strict-aliasing enabled in CFLAGS for your PPC64 build >> (assuming you had built with -O2 or higher)? > > I tried that, but it did not seem to make a difference. If you compile at low optimization levels I assume it goes away? Can you place asm volatile ("" ::: "memory"); between the two tailq macros with the same optimization level? This should prevent gcc from caching anything in registers regardless of the optimization level and would tell us if it's doing something bad. Thanks, Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 19:53:59 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA9031065670 for ; Tue, 18 Sep 2012 19:53:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 8861E8FC15 for ; Tue, 18 Sep 2012 19:53:59 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 353301203C1; Tue, 18 Sep 2012 21:53:54 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 0CAB92847B; Tue, 18 Sep 2012 21:53:54 +0200 (CEST) Date: Tue, 18 Sep 2012 21:53:53 +0200 From: Jilles Tjoelker To: Poul-Henning Kamp Message-ID: <20120918195353.GA56160@stack.nl> References: <95608.1347973160@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95608.1347973160@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 19:54:00 -0000 On Tue, Sep 18, 2012 at 12:59:20PM +0000, Poul-Henning Kamp wrote: > In Varnish I have adopted and today I saw a weird issue > on a PPC64 platform, which makes me wonder if we have a potential > aliasing issue with TAILQs. > The backwards pointers in TAILQs point to the forward pointer of > the previous element, rather than to the top of the previous > element. > To go backwards you therefore have to go two steps backwards and > one step forward. > TAILQ_PREV and TAILQ_LAST do this by assuming that the head and > element structures for a TAILQ are the same, and casts the point > from &(elem->next) to &head, and dereferences head->last as a proxy > for elem->prev. This is elegant, but not type-safe. > I have not 100% confirmed, that in the in problem we had with PPC64, > the compiler in this case fails to spot the aliasing. When I made > the head-struct volatile, the problem went away, which it also did > when I put in a function call at the suspect place to force a > register spill. > I have previously tried to find a way to rewrite TAILQ_LAST/PREV > to be type-safe, but utterly failed, and I have reached the > conclusion that with the current "API" or minor modifications > thereof, that is patently impossible. > It may be a good idea to find some way to make sure the compiler > spots the potential aliasing, but I am not sufficiently up to > date on compiler optimizations to know a safe and reliable way > to do that. (Would explicitly casting throuh a void do it ?) > Details: > https://github.com/varnish/Varnish-Cache/blob/3.0/bin/varnishd/cache_ban.c > lines 388-393. > The problem happens on startup, when the ban_head list is empty, > and I belive the issue is that the (V)TAILQ_INSERT_HEAD() has not > stored the head->last pointer, by the time the (V)TAILQ_LAST() tries > to dereference it, and that the compiler does not spot the aliasing. I think the compiler considers this a strict-aliasing violation. Although the types of tqh_last and tqe_prev match, there is a problem when accessing a TAILQ_ENTRY using an lvalue of type TAILQ_HEAD. A dirty workaround is -fno-strict-aliasing but this reduces optimization opportunities all over the code. An obvious fix is to make TAILQ_ENTRY and TAILQ_HEAD the same type (and not just structurally identical) or to add an intermediate struct which is the same between them. However, I think the TAILQ_LAST and TAILQ_PREV macros are better rewritten using __containerof, also because a subtraction is cheaper than a pointer dereference. Unfortunately, this requires different parameters in the macros and/or the GCC typeof keyword, and will need an explicit check for an empty tail queue or the first element. Something like (untested): #define TAILQ_LAST(head, field) \ (TAILQ_EMPTY((head)) ? NULL : \ __containerof((head)->tqh_last, __typeof__(*(head)->tqh_first), \ field.tqe_prev)) #define TAILQ_PREV(elm, field) \ (*(elm)->tqe_prev != NULL ? NULL : \ __containerof((elm)->tqe_prev, __typeof__(*(elm)), \ field.tqe_prev)) -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 20:14:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7442B106568F for ; Tue, 18 Sep 2012 20:14:54 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 31CB38FC19 for ; Tue, 18 Sep 2012 20:14:53 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DF87E3B74F; Tue, 18 Sep 2012 20:14:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IKEqu1023179; Tue, 18 Sep 2012 20:14:52 GMT (envelope-from phk@phk.freebsd.dk) To: Jilles Tjoelker From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 21:53:53 +0200." <20120918195353.GA56160@stack.nl> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 20:14:52 +0000 Message-ID: <23178.1347999292@critter.freebsd.dk> Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:14:54 -0000 In message <20120918195353.GA56160@stack.nl>, Jilles Tjoelker writes: >A dirty workaround is -fno-strict-aliasing but this reduces optimization >opportunities all over the code. Even if it works, I don't think we should mandate that for all code using >An obvious fix is to make TAILQ_ENTRY and TAILQ_HEAD the same type (and >not just structurally identical) or to add an intermediate struct which >is the same between them. I've tried something along those lines several times, but I have so far not been able to make it work, without a major change to the TAILQ_* api, which I am not prepared to push. >However, I think the TAILQ_LAST and TAILQ_PREV macros are better >rewritten using __containerof, I really don't think that is an improvement, I'd prefer a typesafe standard C solution which static checker tools like Coverity and FlexeLint can see how works. I suspect it would be enough to make the tqh_last and tqe_prev pointer be volatile pointers to struct type pointers, but absent a deeper understanding of whats actually going on I can't tell if that would be a proper solution or merely obfuscation and workaround. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 20:17:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6EC1065673; Tue, 18 Sep 2012 20:17:07 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 979418FC08; Tue, 18 Sep 2012 20:17:07 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 90E403B7A4; Tue, 18 Sep 2012 20:17:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IKH6f1023197; Tue, 18 Sep 2012 20:17:06 GMT (envelope-from phk@phk.freebsd.dk) To: Jeff Roberson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 09:00:38 -1000." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 20:17:06 +0000 Message-ID: <23196.1347999426@critter.freebsd.dk> Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:17:08 -0000 In message , Jeff Roberson writes: >If you compile at low optimization levels I assume it goes away? I don't have access to the machine at this time, and in general I'm not particular focused on PPC64, since this is a general problem on any architecture, as I understand the C-language rules. >Can you place asm volatile ("" ::: "memory"); between the two tailq macros >with the same optimization level? I tried earlier to put a printf("FOO") there, and that fixed it, which I why I diagnosed it as an aliasing issue in the first place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 20:17:07 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6EC1065673; Tue, 18 Sep 2012 20:17:07 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 979418FC08; Tue, 18 Sep 2012 20:17:07 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 90E403B7A4; Tue, 18 Sep 2012 20:17:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q8IKH6f1023197; Tue, 18 Sep 2012 20:17:06 GMT (envelope-from phk@phk.freebsd.dk) To: Jeff Roberson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 18 Sep 2012 09:00:38 -1000." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 18 Sep 2012 20:17:06 +0000 Message-ID: <23196.1347999426@critter.freebsd.dk> Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:17:08 -0000 In message , Jeff Roberson writes: >If you compile at low optimization levels I assume it goes away? I don't have access to the machine at this time, and in general I'm not particular focused on PPC64, since this is a general problem on any architecture, as I understand the C-language rules. >Can you place asm volatile ("" ::: "memory"); between the two tailq macros >with the same optimization level? I tried earlier to put a printf("FOO") there, and that fixed it, which I why I diagnosed it as an aliasing issue in the first place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 20:27:59 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D242106566B; Tue, 18 Sep 2012 20:27:59 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DDCFB8FC12; Tue, 18 Sep 2012 20:27:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8IKRwns075618; Tue, 18 Sep 2012 20:27:58 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8IKRwjx075617; Tue, 18 Sep 2012 20:27:58 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 18 Sep 2012 22:27:56 +0200 From: Baptiste Daroussin To: Eitan Adler Message-ID: <20120918202755.GB26107@ithaqua.etoilebsd.net> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org> <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , arch@FreeBSD.org, Doug Barton Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:27:59 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2012 at 06:03:24PM -0400, Eitan Adler wrote: > On 17 September 2012 17:52, Warner Losh wrote: > [snip] >=20 > >>>> There is a compromise solution here that I have been hesitant to off= er > >>>> because I was really hoping that sanity would prevail. But why not > >>>> switch the default MK_CVS knob over to "no" now? That will give us an > >>>> opportunity to see if there really will be any fallout, and easily f= ix > >>>> it if there is. > >>> > >>> I believe that's already been done. > >> > >> It isn't now, but it sounds to me like you're saying that you're not > >> opposed to doing so? > > > > MK_CVS moving to 'no' by default is something we can do right away, sin= ce it is easy to figure out what went wrong for the people using cvs and pu= tting it back w/o needing to download anything new. Living behind firewall= s can make downloads a pita. I have had systems with very specific holes t= hat made it a PITA to download anything to them, and it is a common occurre= nce. > > > >> Eitan, if you're listening, I'd strike while the iron is hot. :) > > > > Since I thought that had already been done, please do so. Please make = sure that ObsoleteFiles does the right thing too :) Oh, and make sure UPDA= TING is updated. >=20 > I have some surrounding commits to get done first. I'd like to get > some of the existing documentation that refers to CVS removed or > modified first. > There is some consensus for making MK_CVS default to "no" early, so > I'll take that into account and commit that sooner than the above > listed conditions. > Does this change require a OSVERSION bump? I'm inclined to say yes as > the ports infrastructure might need to be aware of the change. >=20 What for? I don't see any reason why the ports tree would like to know about the cvs removal, do you have something in mind? regards, Bapt --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBY2UsACgkQ8kTtMUmk6EwvGgCdEdPhaVZ5X+yW4EJKD0VFrrRI tcUAoL+bYofy69f+fM+In5fQ/aQPFfoa =OzvE -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 21:18:20 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0B8A106566B for ; Tue, 18 Sep 2012 21:18:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7B88FC0A for ; Tue, 18 Sep 2012 21:18:20 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so997097pbb.13 for ; Tue, 18 Sep 2012 14:18:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=kJ0sDoqmN6FZMlkZI3fiaFgwTuAsuDRfGnho+ayEClw=; b=N3O+YDu2SrCd9Ct5mrmUSPFRm5Lt2JHUeMZm4K9Uc+KEK4k6oy/YnJmW3xB2vxPVUW IeLVzbGMMb6IMMripceD7iUW53ONeWNYLB1scWvYw0A7+n6cpGtEaM6hXK65p0yINU45 eLUW89zRUQ4llsnT7l160zDu9YdcxWvHEQemLaIgiLuwu77hDOk/FpNBP5Pu3ndU1xXl /+GgVW6OpvpM7helCQ/KjbW/LF0CcYBuoZyGUo9fEokvoHqy0G89TpxNjQ5rZwJoCS1H WEsnS5jCpJDuUUmLXcTHqZHy882e75SsailzzI7f8gJdrfzTNd9nOScisUlR5YHA3agg OcmQ== Received: by 10.68.233.97 with SMTP id tv1mr1877538pbc.96.1348003099896; Tue, 18 Sep 2012 14:18:19 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id tw5sm552366pbc.48.2012.09.18.14.18.17 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 14:18:19 -0700 (PDT) Date: Tue, 18 Sep 2012 11:17:49 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <23196.1347999426@critter.freebsd.dk> Message-ID: References: <23196.1347999426@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQkG8oNMu2OikTStTqanxDCOhndiIx8tAMAghBBwkIgSaqyNGCkzSIl5QgNu3Ri4BwqNdzSG Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 21:18:20 -0000 On Tue, 18 Sep 2012, Poul-Henning Kamp wrote: > In message , Jeff Roberson writes: > >> If you compile at low optimization levels I assume it goes away? > > I don't have access to the machine at this time, and in general > I'm not particular focused on PPC64, since this is a general > problem on any architecture, as I understand the C-language rules. Have you verified that it actually happens on other architectures? It may be a bug only in the ppc backend and not in bsd code. > >> Can you place asm volatile ("" ::: "memory"); between the two tailq macros >> with the same optimization level? > > I tried earlier to put a printf("FOO") there, and that fixed it, which > I why I diagnosed it as an aliasing issue in the first place. I suggest this approach to further narrow the scope of the issue. Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 21:18:20 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D421065670 for ; Tue, 18 Sep 2012 21:18:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A75A8FC08 for ; Tue, 18 Sep 2012 21:18:20 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so997098pbb.13 for ; Tue, 18 Sep 2012 14:18:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=kJ0sDoqmN6FZMlkZI3fiaFgwTuAsuDRfGnho+ayEClw=; b=UwvOcf4qehhBUMvZyyS0hTDa5rMwha4/hI01nDFJD9WLWmC7ZzzkLLwHQJ1NCEQKvW C6JvWNAM6XszgbJbF69EyMFuv0TwY/GsVoAIvnapJkv2yWn8hvaSXBnPqbhatIbuqxP+ voEjgyLuq9omNEFksgI8nUmdeFOORusA4Igcr5wCowlFH1haiYB2NlQ5WKTyC4+32XfZ EJUHDkReiDthLxFUGuFm6wZVlQAkAsx9rpum7b6+7eq059YYQ0tol5htnSf9bNz1swEi s/U7TFiB1wKaY2HooNyfVdW2iEMcnyICi0ZIt6J3v77VRjabdOP4L73W+6Vhmy7tMV5B D9Pw== Received: by 10.68.233.97 with SMTP id tv1mr1877538pbc.96.1348003099896; Tue, 18 Sep 2012 14:18:19 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id tw5sm552366pbc.48.2012.09.18.14.18.17 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 14:18:19 -0700 (PDT) Date: Tue, 18 Sep 2012 11:17:49 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <23196.1347999426@critter.freebsd.dk> Message-ID: References: <23196.1347999426@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQnJsZqyKxjyGrAMitv9IiBzE/4ED5qAmhXaidia5YNYGpTa18Uf0FlNIs8rKg7Wg42WhGgd Cc: Konstantin Belousov , attilio@freebsd.org, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 21:18:20 -0000 On Tue, 18 Sep 2012, Poul-Henning Kamp wrote: > In message , Jeff Roberson writes: > >> If you compile at low optimization levels I assume it goes away? > > I don't have access to the machine at this time, and in general > I'm not particular focused on PPC64, since this is a general > problem on any architecture, as I understand the C-language rules. Have you verified that it actually happens on other architectures? It may be a bug only in the ppc backend and not in bsd code. > >> Can you place asm volatile ("" ::: "memory"); between the two tailq macros >> with the same optimization level? > > I tried earlier to put a printf("FOO") there, and that fixed it, which > I why I diagnosed it as an aliasing issue in the first place. I suggest this approach to further narrow the scope of the issue. Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 21:59:52 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 806F81065670 for ; Tue, 18 Sep 2012 21:59:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1E968FC0C for ; Tue, 18 Sep 2012 21:59:50 +0000 (UTC) Received: by iayy25 with SMTP id y25so374887iay.13 for ; Tue, 18 Sep 2012 14:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MPG/xvcYOjFOhx6l1/Gj+uBEi8Gy0rzjkTD8tvOzC6M=; b=ZMFBrl3FWjiw4NVaLB3Lnxv+VhxRHMjsZ3Pwn/vaC8HEKyCFKLPmZisFRAhfpK5BVP 8UF7OuQLqyJ/hDiZanQd8cJPF6t+4FJ5wWjSM0q+yVi2pnGPZjc0IYNTRlBVPidvBaKa zP8BHHGegsZVtSgEw89/oqziOlx11iIw9/XfA+bay6ESKl98ILCtvVbAer3MHXvif2at W57JZhUucnb8TI/VOP6JjVHXvDI61I0xELKBWofZ4F50vzXcJMFHwPsit1BHFc+XyaQT wi3+lt2h+KVFLoL8dRU5aImaTPqSv4DbaB9UbvbmIEnPl7lBAzvVPUrb6XfJ3votLyOW 0UlQ== Received: by 10.50.41.129 with SMTP id f1mr1183519igl.57.1348005589723; Tue, 18 Sep 2012 14:59:49 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id cu10sm1347362igc.9.2012.09.18.14.59.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 14:59:48 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120918202755.GB26107@ithaqua.etoilebsd.net> Date: Tue, 18 Sep 2012 15:59:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF35799-A94F-4F42-A2D8-7530FD7662CF@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org> <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> <20120918202755.GB26107@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlZhUFoUWvYr77cIv5Qdq1mWiL2LdEut1rw0n3Uyfyw6Wgsu/dcNSwRlWXscLWDVErqjCaO Cc: Konstantin Belousov , Eitan Adler , Doug Barton , arch@FreeBSD.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 21:59:52 -0000 On Sep 18, 2012, at 2:27 PM, Baptiste Daroussin wrote: > On Mon, Sep 17, 2012 at 06:03:24PM -0400, Eitan Adler wrote: >> On 17 September 2012 17:52, Warner Losh wrote: >> [snip] >>=20 >>>>>> There is a compromise solution here that I have been hesitant to = offer >>>>>> because I was really hoping that sanity would prevail. But why = not >>>>>> switch the default MK_CVS knob over to "no" now? That will give = us an >>>>>> opportunity to see if there really will be any fallout, and = easily fix >>>>>> it if there is. >>>>>=20 >>>>> I believe that's already been done. >>>>=20 >>>> It isn't now, but it sounds to me like you're saying that you're = not >>>> opposed to doing so? >>>=20 >>> MK_CVS moving to 'no' by default is something we can do right away, = since it is easy to figure out what went wrong for the people using cvs = and putting it back w/o needing to download anything new. Living behind = firewalls can make downloads a pita. I have had systems with very = specific holes that made it a PITA to download anything to them, and it = is a common occurrence. >>>=20 >>>> Eitan, if you're listening, I'd strike while the iron is hot. :) >>>=20 >>> Since I thought that had already been done, please do so. Please = make sure that ObsoleteFiles does the right thing too :) Oh, and make = sure UPDATING is updated. >>=20 >> I have some surrounding commits to get done first. I'd like to get >> some of the existing documentation that refers to CVS removed or >> modified first. >> There is some consensus for making MK_CVS default to "no" early, so >> I'll take that into account and commit that sooner than the above >> listed conditions. >> Does this change require a OSVERSION bump? I'm inclined to say yes = as >> the ports infrastructure might need to be aware of the change. >>=20 > What for? >=20 > I don't see any reason why the ports tree would like to know about the = cvs > removal, do you have something in mind? The following ports define CVS_CMD, or have a naked 'cvs' call in them. japanese/man_doc misc/shuffle net_mgt/rancid net_mgt/rancid-devel sysutils/readlink www/tidy-devel all appear to use the system cvs to check out the sources (except many = rancid, not sure what to make of that). Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 22:09:03 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CAE9106578B for ; Tue, 18 Sep 2012 22:09:03 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id B85C48FC08 for ; Tue, 18 Sep 2012 22:09:02 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 1FFA612013E; Wed, 19 Sep 2012 00:08:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E251A2847B; Wed, 19 Sep 2012 00:08:58 +0200 (CEST) Date: Wed, 19 Sep 2012 00:08:58 +0200 From: Jilles Tjoelker To: Poul-Henning Kamp Message-ID: <20120918220858.GB56160@stack.nl> References: <20120918195353.GA56160@stack.nl> <23178.1347999292@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23178.1347999292@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 22:09:03 -0000 On Tue, Sep 18, 2012 at 08:14:52PM +0000, Poul-Henning Kamp wrote: > In message <20120918195353.GA56160@stack.nl>, Jilles Tjoelker writes: > >An obvious fix is to make TAILQ_ENTRY and TAILQ_HEAD the same type (and > >not just structurally identical) or to add an intermediate struct which > >is the same between them. > I've tried something along those lines several times, but I have so far > not been able to make it work, without a major change to the TAILQ_* > api, which I am not prepared to push. > >However, I think the TAILQ_LAST and TAILQ_PREV macros are better > >rewritten using __containerof, > I really don't think that is an improvement, I'd prefer a typesafe > standard C solution which static checker tools like Coverity and > FlexeLint can see how works. I think it is impossible to access another item's tqe_prev with a plain pointer cast and no GCC __typeof__. This is because each time TAILQ_ENTRY is used, it creates a new struct type that cannot be accessed other than via the outer struct (hence needing a 'field' macro parameter (which TAILQ_LAST does not have) and a way to refer to the outer struct type (__typeof__ or a new macro parameter). This is basically the __containerof solution. In the TAILQ_PREV macro, the field parameter together with __typeof__ can be used to construct a cast that will allow legal access to another entry's tqe_prev. However, an extra macro parameter would be required to ensure we do not access the tail queue head using such a pointer. The TAILQ_LAST macro lacks the field parameter to do this. Probably even uglier is to construct a pointer to tqe_prev without involving an lvalue of type struct headname. For example (untested): #define TAILQ_LAST(head, headname, type) \ (**(struct type ***)((char *)(head)->tqh_last + \ offsetof(struct headname, tqh_last))) With this, there is no strict-aliasing violation: a struct type ** object is accessed using an lvalue of the same type. The offsetof expression returns an integer (size_t) and the pointer arithmetic remains within bounds. As with the current illegal code using a pointer cast, it is assumed that TAILQ_HEAD and TAILQ_ENTRY have the same representation. However, it again needs __typeof__ or an extra macro parameter. A less ugly option breaks ABI, but I think API can be preserved: #define TAILQ_HEAD(name, type) \ struct name { struct type *tqh_first, *tqh_last; } #define TAILQ_ENTRY(type) \ struct { struct type *tqe_next, *tqe_prev; } The macros will be easier to understand; they will have more branches but fewer pointer dereferences than what we have now. > I suspect it would be enough to make the tqh_last and tqe_prev > pointer be volatile pointers to struct type pointers, but absent > a deeper understanding of whats actually going on I can't tell > if that would be a proper solution or merely obfuscation and > workaround. The text in the C standard about strict-aliasing does not make an exception for volatile pointers, so it remains undefined behaviour. However, it is quite likely that compilers will generate code as expected. The strict-aliasing rules are generally used to assume certain objects cannot alias, but this is irrelevant when reads and writes have to go to memory directly anyway. Another workaround is GCC's __attribute__((__may_alias__)), added to the TAILQ_HEAD and TAILQ_ENTRY macros. It is also an option to use a "proper" solution using __typeof__ if available and a hack using volatile if not. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 23:30:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 312F1106566C for ; Tue, 18 Sep 2012 23:30:04 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE208FC0A for ; Tue, 18 Sep 2012 23:30:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q8INU2cB026080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 16:30:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q8INU21Q026079; Tue, 18 Sep 2012 16:30:02 -0700 (PDT) (envelope-from jmg) Date: Tue, 18 Sep 2012 16:30:02 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Message-ID: <20120918233002.GE19036@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , arch@freebsd.org References: <95608.1347973160@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95608.1347973160@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 18 Sep 2012 16:30:03 -0700 (PDT) Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 23:30:09 -0000 Poul-Henning Kamp wrote this message on Tue, Sep 18, 2012 at 12:59 +0000: > It may be a good idea to find some way to make sure the compiler > spots the potential aliasing, but I am not sufficiently up to > date on compiler optimizations to know a safe and reliable way > to do that. (Would explicitly casting throuh a void do it ?) Try casting the access through a char pointer. The C99 spec states that you can only access an object through a pointer that is type compatible, or through a char type, though, it isn't clear that from the C99 spec that casting through a char type is enough to break the aliasing... I'm waiting for an answer from a friend who knows this much better than myself... The relevant part of the C99 standard is section 6.5, paragraphs 6 & 7... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 09:33:52 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF615106564A for ; Wed, 19 Sep 2012 09:33:52 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 48B748FC08 for ; Wed, 19 Sep 2012 09:33:51 +0000 (UTC) Received: by lahe6 with SMTP id e6so491635lah.13 for ; Wed, 19 Sep 2012 02:33:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=IZ7YsfvhgXY/O1INmbCTy2nfNz29jUZsMtEegnzbm8k=; b=gxkoWFpwdu5QjOH22IJlJF+4aH/4fxYdOYczzjhhpDQUuPm3x7cUU0469fEEILXRlK Z0lTbiFkn9cFv5p+uNyCTIZgDmcR8KZl+3doeD3xmxODY4IEQHj8SCASsg61RNWDf1Sj K/GX6S4YAb1ZOYgOHhzI/Rv/YGBGymgJisecXjzoQTp6sR04GDfrAn1bueH94pM2fmxO MOQAxCNLB3PgQ/RiRoGHTjKlVP5cLRzrhNNK3/Ytl8YvwM1GgApktLfPbXPN0M7WBlHE sTir5tEuOHeqzEY4tEql4AqJkhnv52sFCZn3OWg8b2TWWWQRoO5ThXhKdGUg7ahkfAhB ZEEw== Received: by 10.152.46.209 with SMTP id x17mr2170209lam.38.1348047230950; Wed, 19 Sep 2012 02:33:50 -0700 (PDT) Received: from dhcp170-234-red.yandex.net (dhcp170-234-red.yandex.net. [95.108.170.234]) by mx.google.com with ESMTPS id hz16sm527265lab.6.2012.09.19.02.33.49 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 02:33:50 -0700 (PDT) Sender: Andrey Zonov Message-ID: <50599179.4020505@FreeBSD.org> Date: Wed, 19 Sep 2012 13:33:45 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <50463026.8000506@FreeBSD.org> <504653CD.2000707@FreeBSD.org> <5046F4E0.6000606@FreeBSD.org> <50561223.7060709@FreeBSD.org> <20120917123719.GS37286@deviant.kiev.zoral.com.ua> In-Reply-To: <20120917123719.GS37286@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig434B811F04FA162BD791E35A" X-Gm-Message-State: ALoCoQkQjbSn7eDQNyJ7bCaYxzDPfoy13MmZRJfOB2qZ4z6H+rOxWejpktfUHD5KaVVK//zhgT5z Cc: Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: [patch] unprivileged mlock(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 09:33:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig434B811F04FA162BD791E35A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/17/12 4:37 PM, Konstantin Belousov wrote: > On Sun, Sep 16, 2012 at 09:53:39PM +0400, Andrey Zonov wrote: >> On 9/5/12 10:44 AM, Andriy Gapon wrote: >>> on 04/09/2012 22:17 Andrey Zonov said the following: >>>> On 9/4/12 8:45 PM, Andriy Gapon wrote: >>>>> on 30/08/2012 12:06 Andrey Zonov said the following: >>>>>> Hi, >>>>>> >>>>>> So, I've got the first version of the patch (attached) which fixes= =20 >>>>>> memory locked limit checking and accounting. >>>>> >>>>> Andrey, >>>>> >>>>> your mlock.patch looks good to me, but I haven't verified pieces un= der >>>>> RACCT. Please try to get a review from a person who is knee-deep in= the >>>>> VM code like alc or your mentor. >>>>> >>>> >>>> Thanks for review! >>>> >>>>> The code should also be sent for vetoing to security@. Not sure if= you >>>>> would get a review there, but absence of nays would be good. >>>>> >>>>> When the code is ready to be committed, please remember about=20 >>>>> memorylocked=3Dunlimited in the default entry of the default login.= conf. A >>>>> big warning about it will have to be posted (in UPDATING and >>>>> current@/stable@ at the very least). >>>>> >>>> >>>> After that amd(8), geli(8) and watchdogd(8) will be broken, because = they=20 >>>> call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLO= CK. I >>>> will prepare patches for raising limits if there is no other solutio= n. >>> >>> Thanks for working on this. >>> BTW, I am not sure why those applications would get broken... >>> We could/should still have memorylocked=3Dunlimited for the 'root' cl= ass. >>> Or is it about something else? >>> >> >> Hmm, I thought that root login class commented out. >> >>>>> Thank you very much for doing this work. >>>>> >>>>> P.S. It would probably make sense to provide some HTTP home for th= is >>>>> patch as well. >>>>> >>>> >>>> Updated patch is here [1]. >>>> >>>> [1] http://people.freebsd.org/~zont/mlock1.patch >>>> >>> >>> Thank you! >>> One additional thing - we probably should retire PRIV_VM_MLOCK and >>> PRIV_VM_MUNLOCK. That would include making changes to >>> sys/i386/ibcs2/ibcs2_misc.c and sys/ofed/drivers/infiniband/core/umem= =2Ec. >>> >> >> They are useful for jails as trasz@ mentioned on IRC. >> >>> P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder = what was >>> the intended use for it (if any)... >>> >> >> So, here is the second version of the patch [1]. >> >> [1] http://people.freebsd.org/~zont/mlock2.patch >=20 > In priv_check_cred(), s/to unprivileged/for unprivileged/. >=20 > In vm_mmap(), on RLIMIT_VMEM failure, racct change shall be rolled back= =2E >=20 > I am not sure why e.g. sys_obreak() forces racct limits instead of obei= ng. >=20 Thanks for review. Updated patch is here [1]. [1] http://people.freebsd.org/~zont/patches/mlock3.patch --=20 Andrey Zonov --------------enig434B811F04FA162BD791E35A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQWZF8AAoJEBWLemxX/CvTXJsH/3SZbso6ufnDCgDqjfPsPCTB zKDVZoIrYwW+E5OOVWSInlyqEFghvZNSUfqqWxQtzdukmbxK5UrQettHeIhXSuib Ke5STyVorGSYArL3cVhbSqJ+ZKwMmFuOLP5y9Y7sdsm3M0SUtnT01lVbcR7On4JE QILHY4GZR5SEo525CcOs3+uxEyczqOVv3jDn7Yt7BBmIkeIE9+rpngJamjp/7E9q hHKkQGbPuxUUxW2I402Y1wSkdXQqNSIT3evSY3vTw9CMKcH9BWQANq1ZG5G6GPr/ BkKa0IUWqK923Ulof0wX1uNKtlwyr0OZuKTJV5081fCKKRHxXIJj9e7UbUxeFJ8= =RSW8 -----END PGP SIGNATURE----- --------------enig434B811F04FA162BD791E35A-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 13:07:22 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 402A7106566B for ; Wed, 19 Sep 2012 13:07:22 +0000 (UTC) (envelope-from sdaoden@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0F8C8FC14 for ; Wed, 19 Sep 2012 13:07:21 +0000 (UTC) Received: by weyx56 with SMTP id x56so675074wey.13 for ; Wed, 19 Sep 2012 06:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:in-reply-to :user-agent:mime-version:content-type:content-transfer-encoding; bh=0kxdh96LmEah2og7wGTOS1E7PyJIRuqA6+wuo8zgUB0=; b=pznW9CbbGh/P+rJljgQNj/N53SPA8PrB0e7YFSBmZQrNIo3EpfcY/B95+u65mtW/pb 5Mau1rEe7jnNZiWVuPe9gUMtyZyoFVReF0K+FcMxJT3yy4GYJnLTMl6dDjy4jR2Z+JT7 qRArFbVAKjVTzidc5YrFKEGxzm4URYyYcaYeE2/y4AjrjynZRDB1QVHFWKsa6rm+/Sqy ADLt50zj0HP+UteJnvDUxzoizRgT5zR4Yuf/6PESRrB6Ff68k7AyjKjoOB9H0ne/cSEx 1z62wHdylSDtcMR2+pohi4gW5YYlO2C+uqGaEdW6IX5e8/f9JpPyWP210RO+d39ASig1 N18w== Received: by 10.216.197.104 with SMTP id s82mr1666730wen.62.1348060040449; Wed, 19 Sep 2012 06:07:20 -0700 (PDT) Received: from dietcurd.wild-life.local ([89.204.130.4]) by mx.google.com with ESMTPS id v3sm27645497wiw.7.2012.09.19.06.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 06:07:18 -0700 (PDT) Date: Wed, 19 Sep 2012 15:07:13 +0200 From: Steffen "Daode" Nurpmeso To: John-Mark Gurney Message-ID: <5059c381.NQi8ZjRVtmejDJ8YX5Um3ADA@dietcurd.wild-life.local> References: <95608.1347973160@critter.freebsd.dk> <20120918233002.GE19036@funkthat.com> In-Reply-To: <20120918233002.GE19036@funkthat.com> User-Agent: S-nail <12.5 7/5/10; s-nail-14-g99de6dd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 13:07:22 -0000 John-Mark Gurney wrote: |Poul-Henning Kamp wrote this message on Tue, Sep 18, 2012 at 12:59 +0= 000: |> It may be a good idea to find some way to make sure the compiler |> spots the potential aliasing, but I am not sufficiently up to |> date on compiler optimizations to know a safe and reliable way |> to do that. (Would explicitly casting throuh a void do it ?) [.] |I'm waiting for an answer from a friend who knows this much better |than myself... | |The relevant part of the C99 standard is section 6.5, paragraphs 6 & = 7... A good rant is on http://blog.qt.digia.com/2011/06/10/type-punning-and-strict-aliasing/= . Down in the comments, as a reply from the original poster of it: Pay attention to what I said and quoted: without the strict-aliasing guarantee, the compiler cannot replace the 10000 4-byte sets with one 40000-byte memset. Isn't that just horrible? For me, when i want to optimize a loop into a memset, i optimize a loop into a memset, and have some fun to see how it performs thereafter. I'll surely have to rework a *lot* of code. It=E2=80=99s quite scary because it says this *will* break stuff. Unbelievable that they simply threw that onto all that code that had been written before, instead of applying it to types and pointers that were explicitly declared to be compatible. Article is worth reading. --steffen From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 16:52:04 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF2711065673 for ; Wed, 19 Sep 2012 16:52:04 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 870218FC0C for ; Wed, 19 Sep 2012 16:52:03 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 09D096FD9; Wed, 19 Sep 2012 18:51:57 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id D0D9785EF; Wed, 19 Sep 2012 16:16:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Steffen "Daode" Nurpmeso References: <95608.1347973160@critter.freebsd.dk> <20120918233002.GE19036@funkthat.com> <5059c381.NQi8ZjRVtmejDJ8YX5Um3ADA@dietcurd.wild-life.local> Date: Wed, 19 Sep 2012 16:16:54 +0200 In-Reply-To: <5059c381.NQi8ZjRVtmejDJ8YX5Um3ADA@dietcurd.wild-life.local> (Steffen Nurpmeso's message of "Wed, 19 Sep 2012 15:07:13 +0200") Message-ID: <86boh2m71l.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, John-Mark Gurney , Poul-Henning Kamp Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 16:52:04 -0000 Steffen "Daode" Nurpmeso writes: > A good rant is on > http://blog.qt.digia.com/2011/06/10/type-punning-and-strict-aliasing/. > [...] > Article is worth reading. It definitely is, but I can't quite make up my mind whether you're being sarcastic or simply didn't understand it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 12:08:17 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F821106566B for ; Thu, 20 Sep 2012 12:08:16 +0000 (UTC) (envelope-from sdaoden@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 7422B8FC18 for ; Thu, 20 Sep 2012 12:08:16 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1057845bkc.13 for ; Thu, 20 Sep 2012 05:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:in-reply-to :user-agent:mime-version:content-type:content-transfer-encoding; bh=jB8/X513wJdBH6Dzw6fV+g5uAwLMZHX2ryPZ1XX6fGU=; b=gnQm53qqg9ZLpTUvFyGOYwUUGO/tNt3bLWyvhK5japUC7ArpMqvLu8O+sXTzZPr5ix Rx/RL8xIvzm2MjO84JmT8PNjDwqLb/t8BUNYCpQFBkkj0+B05GdQCgvU5HxvVu4SxwFw mlcGN6udqunYIcuK9As5AKc0PAsNgrsjcz5bvNdbAeesSS4OKmnHrPKyW/7O+CA2Laet iDvgvh1f9hvqzeZ1FMOhAprf1kYqKs8l3cJX6xEM/0LgTZZiN0oU4lYCz07dIPm1WTJJ BV7zLpbFGzTUFq7YQSROQuESkQVdn1cyk6CwaQ+yDDT9LiJVWI/PYZJBfjatgRMj7TPp VhUg== Received: by 10.204.152.136 with SMTP id g8mr549401bkw.44.1348142895160; Thu, 20 Sep 2012 05:08:15 -0700 (PDT) Received: from dietcurd.wild-life.local ([89.204.138.135]) by mx.google.com with ESMTPS id d13sm3372277bkw.12.2012.09.20.05.08.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 05:08:13 -0700 (PDT) Date: Thu, 20 Sep 2012 14:08:08 +0200 From: Steffen "Daode" Nurpmeso To: Dag-Erling =?utf-8?Q?Sm=C3=B8rgrav?= Message-ID: <505b0728.LBNZBnEmZPF7Y7w7m8ih315j@dietcurd.wild-life.local> References: <95608.1347973160@critter.freebsd.dk> <20120918233002.GE19036@funkthat.com> <5059c381.NQi8ZjRVtmejDJ8YX5Um3ADA@dietcurd.wild-life.local> <86boh2m71l.fsf@ds4.des.no> In-Reply-To: <86boh2m71l.fsf@ds4.des.no> User-Agent: S-nail <12.5 7/5/10; s-nail-14-g99de6dd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Poul-Henning Kamp , John-Mark Gurney Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:08:17 -0000 Dag-Erling Sm=C3=B8rgrav wrote: |Steffen "Daode" Nurpmeso writes: |> A good rant is on |> http://blog.qt.digia.com/2011/06/10/type-punning-and-strict-alias= ing/. |> [...] |> Article is worth reading. | |It definitely is, but I can't quite make up my mind whether you're be= ing |sarcastic or simply didn't understand it. | |DES |--=20 |Dag-Erling Sm=C3=B8rgrav - des@des.no most likely me failing email conversation deliberatly. Besides FreeBSD made my living, you can say whatever you want! Thanks! and ciao, --steffen From owner-freebsd-arch@FreeBSD.ORG Fri Sep 21 21:14:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 820BC106566C for ; Fri, 21 Sep 2012 21:14:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id B5E7B8FC14 for ; Fri, 21 Sep 2012 21:14:53 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q8LLEqt0024374; Fri, 21 Sep 2012 16:14:53 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q8LLEqFd024373; Fri, 21 Sep 2012 16:14:52 -0500 (CDT) (envelope-from brooks) Date: Fri, 21 Sep 2012 16:14:52 -0500 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20120921211452.GB24285@lor.one-eyed-alien.net> References: <20120917201919.GA43626@lor.one-eyed-alien.net> <65917.1347946209@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <65917.1347946209@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 21:14:54 -0000 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2012 at 05:30:09AM +0000, Poul-Henning Kamp wrote: > In message <20120917201919.GA43626@lor.one-eyed-alien.net>, Brooks Davis = writes > : >=20 > >As part of an effort to improve our ability to create full system images > >without root access I would like to import NetBSD's version of mtree. > >By doing so we would gain the -C option which produces mtree files > >compatible with libarchive and makefs (one line per file with full > >path) and the -N option which allows a stand alone set of passwd and > >group files. >=20 > Please make sure we don't loose the -f -f comparison option. I've been testing a port of -f -f and was surprised to discover that the differences in the time=3D field aren't reported even though they are checked. Did you mean to do that? -- Brooks --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQXNjMXY6L6fI4GtQRAqWvAJsGUs0578f2RrycAeLQjy6JJNqkvwCdGq0f WKC9thpHL66ofSD65/0LnV0= =umtC -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8--